HealthCare.gov : ce qui a sauvé le site, ce n'était pas seulement d'ajouter du monde

Cas réel et public. Hábil n'a pas participé à HealthCare.gov. Nous l'analysons à partir des rapports du gouvernement des États-Unis et de la presse ; les sources figurent à la fin.

Il est minuit, le 1er octobre 2013. Le personnel sous contrat qui exploite le système de comptes et d'identité de HealthCare.gov regarde le site démarrer. Il vient d'ouvrir, et c'est par lui que des millions de personnes doivent comparer et souscrire une assurance santé. L'un d'eux s'en souviendrait ainsi devant les auditeurs : « Nous étions assis au bureau à minuit quand il a commencé à tourner, et ça ne s'annonçait pas bien. Tout virait au rouge sur nos écrans » (traduction propre) [1].

Ce jour-là, 250 000 utilisateurs sont arrivés sur le site en même temps, bien plus que prévu. Les pannes ont commencé deux heures après l'ouverture. À la fin de la journée, selon le rapport de l'Inspecteur général du ministère de la Santé des États-Unis, seules six personnes avaient réussi à envoyer une demande et à choisir une formule [1].

Six. Sur le site qui devait servir des millions de personnes dans 36 États [1].

Voici l'histoire de la manière dont ce site s'est rétabli en deux mois environ. Je ne la raconte ni pour la politique ni pour l'assurance santé. Je la raconte parce que tout directeur technique s'est déjà trouvé, à plus petite échelle, dans la même salle : un système qui ne peut pas tomber, une date qui ne bouge pas et quelqu'un autour de la table qui dit « ajoutons du monde ». L'intérêt du cas, c'est que cela avait déjà été tenté, et que cela n'a pas suffi à lui seul. Le site s'est rétabli lorsque, en plus d'ajouter du monde, la manière de travailler a changé : un petit noyau d'ingénieurs expérimentés, intégré à une seule table avec l'agence et les prestataires, des métriques sur l'ensemble du système et des priorités taillées sans pitié. Les auditeurs relèvent plusieurs causes, et non une seule [1].

Soixante-douze heures avant

Le problème n'a pas commencé le 1er octobre. Les auditeurs du gouvernement en font remonter la trace à plusieurs années. L'Inspecteur général (OIG, le bureau qui audite le ministère de la Santé) a interrogé 86 fonctionnaires et prestataires et examiné des milliers de documents. Sa conclusion principale tient en une ligne : le plus grave a été l'absence d'un leadership clair, qui a retardé les décisions, laissé des tâches mal définies et empêché de voir l'ampleur du problème pendant qu'il grandissait [1].

Les derniers jours avant le lancement semblent écrits pour un film.

Le 24 septembre, la responsable de la sécurité informatique de l'agence qui construisait le site (les CMS, les Centres des services Medicare et Medicaid) a averti qu'une pièce centrale ne satisfaisait pas raisonnablement aux exigences de sécurité. Le 27, au lieu d'une autorisation normale, l'administratrice des CMS a signé une autorisation provisoire d'exploitation de six mois [1].

Le 26 septembre, à moins de cinq jours du démarrage, des techniciens des CMS ont effectué des tests de charge et découvert que le site supportait bien moins d'utilisateurs simultanés que prévu. Ils ont pris la voiture jusqu'aux bureaux du fournisseur d'infrastructure et lui ont demandé de doubler toute la capacité en 72 heures. Un responsable du fournisseur l'a raconté ainsi : « La demande était de tout doubler à 72 heures du lancement. […] Nous louions des avions pour faire venir du matériel destiné à d'autres clients » (traduction propre) [1].

Le 29 septembre, le système de comptes et d'identité, la porte par laquelle devait passer chaque utilisateur, a subi des pannes. Le même jour, l'administratrice des CMS a écrit au directeur technique des États-Unis que le site serait prêt le 1er octobre [1].

Il y a un détail que le rapport souligne et qui vaut pour n'importe quelle entreprise : plusieurs membres de l'équipe croyaient que la date du site figurait dans la loi. Ce n'était pas le cas. La loi exigeait que la couverture commence au plus tard le 1er janvier 2014 et laissait au ministère de la Santé le soin de fixer la période d'inscription, qui, par voie réglementaire, a démarré le 1er octobre 2013 [1]. S'y ajoutait le poids de la politique : la Maison-Blanche s'était engagée publiquement sur cette date, et au ministère on craignait qu'un retard ne donne des arguments à ceux qui cherchaient à abroger la loi au Congrès [1]. La date que personne n'osait déplacer ne venait pas de la loi, mais d'un règlement et de la politique. Et personne à la direction des CMS n'a formellement discuté de la déplacer [1].

Et un autre encore : il n'y a pas eu de tests complets de bout en bout. Un prestataire l'a résumé pour les auditeurs : « Les tests de bout en bout sont essentiels. Ne pas les faire, c'est du suicide » (traduction propre) [1].

On avait déjà essayé d'ajouter du monde

Voici la donnée que presque personne ne raconte à propos de ce cas.

En août 2013, deux mois avant le lancement, les CMS ont vu que le projet avait pris beaucoup de retard et ont réagi comme réagirait presque n'importe quelle organisation : ils ont affecté temporairement 60 personnes de plus, venues d'autres services, aux 51 qui travaillaient déjà sur le site. Une hausse de 117 % [1].

Cela n'a pas suffi. Le rapport lui-même recueille ce qu'ont ressenti certaines des personnes impliquées : qu'il était déjà trop tard pour en faire venir d'autres, vu la raideur de la courbe d'apprentissage, et qu'elles étaient gênées d'« entraîner d'autres personnes dans un gâchis » (traduction propre) [1].

En 1975, Frederick P. Brooks Jr., qui avait dirigé le développement du système d'exploitation OS/360 chez IBM, a écrit dans The Mythical Man-Month une phrase connue aujourd'hui comme la loi de Brooks : « Ajouter des personnes à un projet logiciel en retard le retarde davantage » (traduction propre) [5]. Son raisonnement : le travail ne se découpe pas en morceaux indépendants, chaque nouvelle personne a besoin que quelqu'un lui explique, et les canaux de communication croissent plus vite que l'équipe.

Il convient d'être précis. Le rapport de l'OIG ne cite pas Brooks, et l'on ne peut pas affirmer que ces 60 personnes ont retardé le site. Ce qu'il documente, en revanche, c'est que les ajouter tard, sans leadership clair et sur un projet désorganisé, n'a pas évité le dénouement. Le lien avec Brooks est le mien, et je le propose comme une lecture, non comme une constatation des auditeurs.

Deux semaines à l'aveugle

Après le 1er octobre, la première réaction a été, elle aussi, d'envoyer plus de monde. En quelques jours, du personnel des CMS et du prestataire principal s'est installé au centre de commandement du prestataire à Herndon, en Virginie, et d'autres prestataires sont venus s'y joindre [1].

Mais il y avait un problème de fond : personne ne voyait le système complet. Chaque prestataire surveillait sa propre pièce et ne pouvait pas voir les autres, alors qu'elles fonctionnaient toutes ensemble. Il y avait plusieurs « centres de commandement » en des lieux différents, l'un à Herndon et l'autre à Columbia, dans le Maryland, chacun avec ses outils, et aucun responsable ni aucune équipe n'avait de vision de l'ensemble du système et l'autorité pour agir. Personne n'assurait formellement le rôle d'intégrateur de systèmes [1].

L'un des ingénieurs qui arriveraient plus tard l'a dit lors d'une conférence en 2014 : « Il n'y avait aucun endroit où regarder pour savoir si le site était en ligne ou non, à part CNN, et c'est littéralement ainsi que nous apprenions les problèmes une bonne partie du temps au début » (traduction propre) [1].

Pour compliquer les choses, le matin du lancement, le gouvernement fédéral a fermé faute de budget. La fermeture a duré 16 jours, et le personnel des bureaux clés du projet a été réduit à environ un tiers [1].

Pendant ce temps, le site n'inscrivait presque personne. Selon TIME, sur tout le mois d'octobre, 26 794 personnes se sont inscrites par le marché fédéral [4]. Et la capacité réelle, selon un membre de l'équipe qui l'a ensuite réparé, était de « peut-être quelques milliers d'utilisateurs » (traduction propre), alors que le chiffre officiel parlait de 50 000 [4].

17 octobre : rafistoler ou jeter ?

Le 17 octobre, selon la reconstitution du journaliste Steven Brill dans TIME, on discutait à la Maison-Blanche de l'opportunité de réparer le site ou de le jeter pour repartir de zéro [4]. Ce jour-là, Todd Park, alors directeur technique de la Maison-Blanche, a changé de travail sans changer de bureau : « Le 17 octobre, je suis passé de CTO de la Maison-Blanche à réparateur de HealthCare.gov à plein temps » (traduction propre) [4].

Park a recruté un groupe d'ingénieurs qui n'avaient pas participé à la construction. L'OIG les décrit comme « plusieurs dirigeants et ingénieurs des principales entreprises technologiques » (traduction propre) [1]. Parmi eux se trouvait Mikey Dickerson, ingénieur en fiabilité des sites chez Google, c'est-à-dire quelqu'un dont le travail quotidien consistait à empêcher un site gigantesque de tomber [4]. Un détail du rapport en dit long sur la manière dont ils sont arrivés : ils ont en grande partie donné leur temps, même si, en raison des règles d'achat public, ils ont été payés à l'heure par l'intermédiaire de l'un des prestataires [1].

La première chose qu'ils ont faite n'a pas été de programmer des correctifs. Ce fut de mesurer. Le soir du vendredi 18 octobre, selon TIME, Gabriel Burt, directeur technique d'une entreprise d'analyse de données, et d'autres ont passé environ cinq heures à monter un tableau de bord, parce que le site n'avait aucun moyen rapide de savoir ce qui se passait [4]. Grâce à ce tableau de bord, ils ont trouvé l'un des premiers correctifs rapides : le soir du 22 octobre, le temps de chargement d'une page est passé de huit secondes à deux [4].

Ce même 22 octobre, la secrétaire à la Santé a annoncé publiquement ce qu'elle a appelé un « tech surge », une offensive technologique : Jeff Zients, un administrateur rompu à la direction d'entreprises, rejoignait le projet comme conseiller en gestion, avec des « experts et spécialistes » du gouvernement, des prestataires et de l'industrie, « y compris des vétérans des grandes entreprises de la Silicon Valley », et « une poignée » de membres du programme Presidential Innovation Fellows de la Maison-Blanche (traduction propre) [3].

Première décision importante, prise avec ce groupe : refactoriser le code existant, et non reconstruire à partir de zéro. Repartir de rien aurait coûté un temps dont on ne disposait pas, et le personnel de l'agence et des prestataires était disposé à travailler avec les nouveaux venus [1].

La salle de Columbia

Fin octobre, le centre de commandement a déménagé dans une salle d'environ 370 mètres carrés (4 000 pieds carrés) que l'un des prestataires louait dans un parc de bureaux à Columbia, dans le Maryland [4]. Avec le temps, elle deviendrait le centre d'opérations officiel du site [1].

Dickerson a convoqué la première réunion debout le 24 octobre. À partir de là, tous les jours, week-ends compris, en octobre et en novembre : à 10 h et à 18 h 30, environ 45 minutes chacune, avec une ligne téléphonique ouverte 24 heures sur 24 pour que ceux qui travaillaient ailleurs puissent parler aux autres dès que quelque chose surgissait [4].

Les règles, il les a affichées sur un mur, à l'extérieur de la salle de contrôle. TIME les reproduit [4] :

1. « La salle de crise et les réunions servent à résoudre des problèmes. Il existe bien d'autres lieux où les gens consacrent leur énergie créative à rejeter la faute sur autrui » (traduction propre).
2. « Ceux qui doivent prendre la parole sont les personnes qui connaissent le mieux un sujet, et non les plus haut placées » (traduction propre).
3. « Il faut rester concentrés sur les problèmes les plus urgents, comme ce qui nous fera mal dans les prochaines 24 à 48 heures » (traduction propre).

Le rapport de l'OIG décrit le même changement avec d'autres mots. On a adopté une culture « sans badge et sans titre » (traduction propre) : les tâches étaient attribuées selon la compétence et la disponibilité, que la personne soit employée du gouvernement ou de n'importe quel prestataire [1]. Pour la première fois, l'équipe technique et celle chargée des politiques du programme travaillaient ensemble. L'un des ingénieurs l'a décrit ainsi : « Nous avions les gens chargés des politiques qui déchiffraient les messages d'erreur. Que faisait ou ne faisait pas le code ? Qu'était-il censé se passer ? » (traduction propre) [1]. Et l'agence a engagé un intégrateur technique de systèmes, quelqu'un dont le travail consistait à faire en sorte que toutes les pièces se parlent. Selon le rapport, cela a amélioré la coordination « de l'avis de tous » (traduction propre) [1].

Il y a une phrase d'un fonctionnaire des CMS, recueillie par les auditeurs, qui résume le cas mieux que n'importe quelle analyse : « Les CMS n'avaient pas besoin d'une offensive technologique ; nous avions besoin d'une offensive organisationnelle » (traduction propre) [1].

Et la pression pour ajouter du monde ? Elle était toujours là. Brill le raconte ainsi : Zients avait « carte blanche pour ajouter des ressources », mais mettre dix personnes sur un correctif qui prendrait dix jours à un seul programmeur n'en fait pas un projet d'une journée. « Programmer ne fonctionne pas ainsi » (traduction propre) [4].

L'horloge de novembre

Le 25 octobre, Zients a fixé publiquement un objectif : le site fonctionnerait bien pour la grande majorité des utilisateurs fin novembre [1]. Les responsables techniques de la salle ont dit ensuite aux auditeurs qu'on ne les avait pas consultés sur cette date [1].

Le chemin vers cet objectif fut dur. Fin octobre, deux pannes de l'équipement du fournisseur d'infrastructure ont laissé le site indisponible 24 et 36 heures [1]. Certains ont dormi dans des hôtels voisins et ont travaillé par équipes de 24 heures [1]. « Ce furent des jours sombres » (traduction propre), a dit un fonctionnaire [1].

Mais les chiffres ont commencé à bouger. Selon le rapport des CMS du 1er décembre, cité par l'OIG, le temps pendant lequel le site fonctionnait est passé de 42 % début novembre à plus de 90 % fin novembre [1]. (TIME a rapporté 43 % et 95 % [4] ; j'utilise le chiffre du rapport officiel.) Au 1er décembre, le site tenait plus de 35 000 utilisateurs simultanés sans tomber, selon l'OIG ; TIME a parlé d'au moins 50 000 [1][4]. Il y avait désormais des tableaux de bord de performance de l'ensemble du système et, quand la charge débordait, une « salle d'attente » qui demandait à l'utilisateur de patienter ou de laisser son adresse électronique [1].

Le délai pour avoir une couverture au 1er janvier a été repoussé du 15 au 24 décembre. Le dernier jour, le site a reçu 49 156 utilisateurs simultanés, selon l'OIG [1] ; TIME a rapporté un pic plus élevé, de 83 000, le 23 décembre [4]. Au 28 décembre, environ 1,2 million de personnes avaient choisi une formule par HealthCare.gov [1]. À la clôture de la première période d'inscription, 5,4 millions de personnes avaient choisi une formule sur le marché fédéral [1].

De six personnes le premier jour à plus d'un million en décembre.

Ce que cela a coûté

Le sauvetage n'a pas effacé l'addition. L'OIG rapporte que six contrats clés avaient été estimés au départ à 464 millions de dollars et qu'au début de 2014 on les chiffrait déjà à 824 millions ; celui du système central est passé de 58 à 207 millions [1]. Le Bureau de la responsabilité gouvernementale (GAO) a constaté que le site avait été lancé sans vérifier qu'il satisfaisait à ses exigences de performance, et que les engagements du contrat du système central étaient passés de 56 à plus de 209 millions entre septembre 2011 et février 2014 [2].

En janvier 2014, les CMS ont changé de prestataire principal. Le prestataire sortant, dit l'OIG, l'a appris par le Washington Post quelques jours avant l'arrivée du nouveau [1].

Ce qu'enseigne ce cas

1. Ajouter du monde ne suffit pas, et parfois cela gêne

Il y a eu deux vagues de renforts. Celle d'août 2013, 60 personnes de plus sur un projet sans leadership clair, n'a pas évité le désastre [1]. Celle d'octobre, qui a elle aussi ajouté du personnel de l'agence, des prestataires et du secteur privé, en grande partie en trois semaines [1], a bel et bien fait partie du rétablissement, parce qu'elle est arrivée accompagnée de leadership, de métriques, d'intégration et de priorités claires [1]. Le cas ne permet pas d'attribuer le résultat à un seul facteur.

Soyons honnêtes avec la donnée : le sauvetage ne s'est pas fait avec moins de monde. Il s'est fait avec d'autres personnes, organisées autrement. La différence n'a pas tenu au nombre, mais à qui est arrivé, à la manière dont ces personnes se sont intégrées et aux instruments avec lesquels elles ont travaillé. Brooks avait raison dans sa mise en garde, mais le cas ne dit pas « n'ajoutez jamais personne ». Il dit : n'attendez pas du nombre qu'il règle ce que l'organisation ne résout pas.

2. Un petit noyau, expérimenté et intégré

Le noyau arrivé à la mi-octobre était restreint : « plusieurs » ingénieurs, selon l'OIG ; « une poignée » de membres de ce programme de la Maison-Blanche, selon l'annonce officielle [1][3]. Ils ne sont pas venus faire le travail de tout le monde. Ils sont arrivés avec l'expérience de sites qui ne tombent pas, se sont assis avec les ingénieurs des prestataires, qui connaissaient déjà le code, et les ont dirigés. TIME parle de « dizaines » d'ingénieurs, disposés et même enthousiastes, que ce noyau a coordonnés (traduction propre) [4].

Ce noyau a été une pièce, non toute l'explication. Parmi les facteurs clés du rétablissement, l'OIG souligne que tout le personnel des CMS et des prestataires a travaillé comme une seule équipe, sans badge, et une « priorisation impitoyable » (traduction propre) qui a aligné le travail sur les objectifs les plus importants et atteignables [1].

Le mot clé est intégré. Sans badge et sans titre : celui qui sait parle ; celui qui peut prend la tâche. Un ingénieur externe qui arrive pour « auditer » depuis l'extérieur ajoute une couche de plus. Un ingénieur qui s'assoit dans la même salle, avec les mêmes règles, en retire une.

3. Mesurer avant de réparer

La première chose a été un tableau de bord monté en une nuit [4]. Avant cela, la meilleure source pour savoir si le site était en ligne était la télévision [1]. Sans métriques, chaque nouvelle personne donne son avis ; avec des métriques, chaque nouvelle personne s'attaque à ce que le tableau de bord signale.

4. Une seule table, avec des règles

Non pas une réunion quotidienne de plus, mais la réunion : une seule salle, deux points par jour, 45 minutes, une ligne ouverte en permanence et trois règles au mur [4]. On discute de ce qui fera mal dans les prochaines 24 à 48 heures, celui qui sait prend la parole et l'on ne cherche pas de coupables. C'est l'opposé de plusieurs centres de commandement qui ne se voient pas entre eux [1].

5. Quelqu'un responsable de faire en sorte que tout se parle

Avant le lancement, personne n'assurait le rôle d'intégrateur de systèmes et chaque prestataire regardait sa pièce [1]. Pendant le sauvetage, l'agence en a engagé un [1]. Quand un système est fait de nombreuses pièces et de nombreux fournisseurs, quelqu'un doit être responsable des jointures. Si personne ne l'est, c'est précisément là que vit le problème.

6. La date que personne ne déplace mérite une question

La date du 1er octobre n'était pas fixée par la loi : elle venait d'un règlement et un engagement politique la maintenait, et personne n'a formellement discuté de la déplacer [1]. Avant d'ajouter du monde pour tenir une date, il vaut la peine de demander qui l'a fixée, ce qui se passe si elle bouge et quel est le minimum qui doit fonctionner ce jour-là.

Application : deux ingénieurs clés de moins avant le Buen Fin

Scénario (illustratif, sans client ni cas réel). J'applique les leçons de HealthCare.gov à une situation que beaucoup de dirigeants au Mexique reconnaîtront.

Nous sommes en septembre. Votre commerce en ligne se prépare au Buen Fin, le week-end de novembre où se concentre une bonne partie des ventes de l'année. En une même quinzaine, les deux ingénieurs qui connaissent le mieux l'intégration entre la boutique, les stocks et les paiements démissionnent. Il reste sept semaines.

La réaction naturelle est celle d'août 2013 : « embauchons-en cinq ». Les leçons du cas suggèrent un autre ordre :

1. D'abord, mesurer. Avant leur départ, demandez-leur une séance pour rendre visible ce qu'eux seuls voyaient : quelles alertes ils surveillaient, quels tableaux de bord, quels processus ils redémarraient à la main. S'il n'existe pas de tableau de bord du parcours d'achat complet (de la boutique au paiement et aux stocks), c'est le premier livrable, pas le dernier.
2. Ensuite, ajouter peu de monde, et expérimenté. Pas cinq profils génériques qu'il faut former à sept semaines de la haute saison. Un ou deux ingénieurs qui ont déjà travaillé sur des intégrations semblables et en période de fort volume, que votre équipe peut faire passer en entretien avant qu'ils ne commencent.
3. Les intégrer, pas les affecter. Qu'ils entrent avec les comptes de votre entreprise, dans vos dépôts, à vos horaires et dans vos réunions. Sans « équipe du fournisseur » ni « équipe maison » : une seule table.
4. Une réunion courte, avec des règles. Deux points par jour pendant les semaines qui précèdent, centrés sur ce qui peut faire tomber les ventes dans les prochaines 48 heures.
5. Tailler sans pitié. Ce qui n'est pas indispensable pour vendre, encaisser et livrer ce week-end-là est reporté.
6. Revoir la date de chaque changement, pas celle du Buen Fin. Celle-là ne bouge pas. Mais celle de la refonte du panier, celle de la nouvelle passerelle de paiement ou celle de la migration du catalogue, peut-être que si.

Vu ainsi, le Buen Fin ne se gagne pas avec plus de monde. Il se gagne avec les bonnes personnes, à temps et assises à la même table.

Cinq questions pour votre prochain comité

1. Si demain partent les deux ingénieurs qui en savent le plus sur nos intégrations, qu'est-ce qui cesse de fonctionner, et quelqu'un d'autre le sait-il ?
2. Avons-nous un tableau de bord du parcours complet qui compte pour l'activité, ou chaque service ne surveille-t-il que sa pièce ?
3. Qui est responsable des jointures entre nos systèmes et nos fournisseurs ?
4. Quand nous ajoutons des personnes à un projet en retard, combien de temps leur faut-il pour être utiles, et qui les intègre ?
5. Les dates qui « ne peuvent pas bouger » figurent-elles dans un contrat, dans une loi ou dans une présentation ?

Si, à deux de ces questions ou plus, la réponse est « je ne sais pas », votre prochain mois d'octobre se trouve peut-être là.

Ce que fait Hábil quand il manque une connaissance critique

Hábil est une société mexicaine de conseil en ingénierie, fondée en 2006, qui renforce avec des ingénieurs seniors les équipes d'entreprises au Mexique et aux États-Unis. Nous n'envoyons pas « plus de monde » : nous présentons des profils expérimentés en intégration, cloud et systèmes réglementés, que vous faites passer en entretien et validez avant qu'ils ne commencent, et qui travaillent dans vos contrôles : avec l'identité de votre entreprise, dans vos dépôts et sur une plage horaire quotidienne partagée avec votre équipe.

Vous pouvez commencer avec un ou deux ingénieurs qui s'intègrent à votre équipe, avec une cellule que nous coordonnons ou avec un projet au périmètre fermé. Voyez la page Renforcer votre équipe d'ingénieurs.

Demandez votre première conversation, sans frais. Elle part de ce que vous devez soutenir ou construire, du profil qui convient et de la forme de travail adaptée. Écrivez-nous sur WhatsApp.

Questions fréquentes

Qu'est-ce que le « tech surge » de HealthCare.gov ?

C'est le nom que le ministère de la Santé des États-Unis a donné, le 22 octobre 2013, au renfort chargé de réparer le site : un conseiller en gestion, Jeff Zients, et des experts du gouvernement, des prestataires et d'entreprises technologiques [3]. Le noyau technique a été recruté par la Maison-Blanche parmi des ingénieurs qui n'avaient pas construit le site [1].

Combien de temps a duré le sauvetage ?

L'OIG conclut que les CMS ont rétabli le site pour un usage intensif en deux mois environ : l'objectif d'amélioration a été atteint le 1er décembre 2013 [1].

Que dit la loi de Brooks ?

En traduction libre : « Ajouter des personnes à un projet logiciel en retard le retarde davantage » (traduction propre). Elle vient du livre The Mythical Man-Month, de Frederick P. Brooks Jr., publié en 1975 [5]. C'est une mise en garde, non une interdiction : le coût réside dans le temps nécessaire pour intégrer chaque personne et dans la communication qui se multiplie.

Alors, ne faut-il jamais ajouter des ingénieurs à un projet en retard ?

Le cas ne dit pas cela. En octobre 2013, on a ajouté du monde et le site s'est rétabli, mais ces personnes sont arrivées avec de l'expérience, se sont intégrées à une seule table sans distinction d'employeur et ont travaillé avec des métriques et des priorités resserrées [1][4]. Le cas ne permet pas d'attribuer le résultat à un seul facteur. Ce qui n'a pas suffi, c'est d'ajouter du monde sans leadership ni visibilité [1].

Hábil a-t-elle participé au cas HealthCare.gov ?

Non. C'est un cas public, documenté par le gouvernement des États-Unis et par la presse. Nous l'utilisons parce que ses leçons s'appliquent à toute équipe qui soutient un système qui ne peut pas tomber.

Combien de temps faut-il à un ingénieur de Hábil pour s'intégrer à mon équipe ?

Cela dépend de trois choses : le profil dont vous avez besoin, les entretiens par lesquels votre équipe le valide et le temps que met votre entreprise à lui ouvrir des comptes et des accès à vos dépôts. Lors de la première conversation, nous définissons le profil et vous disons dans quel délai il peut commencer dans votre contexte.

Les citations sont traduites de l'anglais (traduction propre). Les chiffres sont ceux que rapporte chaque source ; lorsque deux sources ne concordent pas, le texte le dit et retient le chiffre officiel.