Les règles révisées du leadership en ingénierie

• Récapitulatif de 5 règles majeures du leadership en ingénierie, validées et reformulées au cours de l’année écoulée dans un contexte de bascule vers les outils d’IA et d’hypercroissance, avec des cas de projets réels à l’appui
• Les migrations peuvent désormais être menées à 95 % par une seule personne plutôt que par une équipe, et être terminées en 10 % du temps auparavant nécessaire ; plus le coût initial baisse, plus l’impact du jugement individuel augmente
• Le premier jet de code est quasiment gratuit, mais le coût d’un code qui fonctionne réellement dépend du harness de développement — tests, CI/CD, etc. — et n’est donc pas gratuit
• Pour la plupart des processus, le cas standard peut être entièrement automatisé par des agents ; pour la première passe de revue de code aussi, un bon harness est plus rapide et plus efficace qu’un humain
• Pour bénéficier réellement des avantages de l’IA, il faut comme prérequis des équipes pérennes dotées de contexte métier et une prise de décision rapide et robuste

---

Contexte

• Travail en environnement d’hypercroissance du début 2014 à la fin 2020 ; la plus grande valeur de l’hypercroissance est que les erreurs se révèlent le mois suivant, pas l’année suivante (quand on va vite, les problèmes explosent vite)
• Si l’hypercroissance revient en tête récemment, c’est à cause de la croissance rapide d’Imprint, des recrutements massifs de l’an dernier, et du changement de rythme rendu possible par la bascule vers les outils d’IA
• Cet article présente à la fois les règles de leadership reformulées et les projets concrets de l’année passée qui ont conduit à ces convictions

Règles révisées

1. Les migrations peuvent être réalisées par une personne, pas forcément par une équipe

• Même des changements vastes et complexes peuvent être possédés à 95 % par une personne ou une petite équipe pilote, et être menés en 10 % du temps d’avant
• Plus le coût initial baisse, plus les gains et les pénalités liés à la qualité de chaque migration augmentent
  • Même de petits défauts détruisent le modèle mental logiciel des collègues qui doivent ensuite maintenir le système
• L’impact du jugement individuel sur l’entreprise est plus grand que jamais

2. Le premier jet de code est presque gratuit, mais le coût du code qui fonctionne dépend du harness de développement

• Nous sommes entrés dans une époque où tout le monde doit écrire du code, mais écrire un code fiable tout en évitant les edge cases sales reste difficile
• Cette difficulté dépend du harness de développement : tests, CI/CD, environnements de validation, prévisualisation des changements, etc.
• Même dans une entreprise où « tout le monde code », l’enjeu n’est pas que l’équipe marketing réduise elle-même l’allocation serveur, mais qu’il existe des frontières sûres lui permettant de contribuer sans risque (comme un produit SaaS qui autorise la personnalisation via du logiciel)
• Ce qui avait le plus de valeur pour accélérer l’ingénierie il y a deux ans reste encore aujourd’hui ce qui a le plus de valeur

3. Optimiser le cas standard des processus pour les agents

• Avec le bon harness, les bons contrôles, le bon contexte métier et le bon jugement du concepteur, il est possible d’automatiser complètement le cas standard de la plupart des processus
• Le cas standard de la revue de code humaine est plus lent et moins efficace qu’une revue de code faite par un bon harness
  • Le harness rate des choses, mais les humains aussi, et dans la plupart des zones les changements sont relativement sûrs
  • Certaines zones à haut risque restent des exceptions ; si cette distinction est bien captée, on gagne en vitesse sans augmenter le risque, sinon on crée d’innombrables problèmes
• Corollaire : des processus de planification comme les sprints hebdomadaires ou bimensuels opèrent à un niveau trop bas ; la planification conjointe des humains doit se faire à un niveau plus élevé

4. Les équipes pérennes à forte ownership, avec contexte métier, sont encore plus importantes

• Leçon apprise chez Uber : des équipes durables et solides produisent des résultats presque magiques grâce à l’accumulation de contexte métier, à la camaraderie et à un fort sens de l’ownership
• Même dans une époque où le coût d’exécution a chuté, il faut toujours faire les bonnes choses, et cela n’est devenu que légèrement plus facile, pas radicalement
  • Exemple : les données nécessaires à une optimisation en production n’étaient tout simplement pas collectées ; la solution du harness était donc raisonnable mais fausse, et la seule vraie solution consistait à instrumenter l’information manquante
• Opposition à l’idée reçue selon laquelle une entreprise AI-first peut fonctionner avec une poignée d’ingénieurs géniaux : même des individus au jugement exceptionnel se heurtent aux limites du manque de contexte métier, donc l’unité fondamentale reste l’équipe pérenne

5. Une prise de décision rapide, bonne et robuste est la condition préalable pour profiter de l’IA

• Pour remplacer une revue juridique par de l’automatisation, l’équipe Legal doit pouvoir s’engager sur ce changement ; cela dépend d’une conception soigneuse et de la volonté des équipes de collaborer
• Les bénéfices liés à l’accélération de l’exécution ne sont possibles que si l’on sait prendre des décisions rapides, robustes et de qualité
• C’est la principale raison pour laquelle le rôle moyen du CTO est aujourd’hui beaucoup plus technique et moins bureaucratique qu’il y a un an
  • En cas de désaccord entre équipes, c’est souvent la seule personne capable de prendre une décision contraignante ; pour maintenir la vitesse, elle doit donc décider en permanence
  • Il ne s’agit pas de dire que les dirigeants prennent forcément de meilleures décisions, mais tant qu’ils sont alignés entre eux et respectent les décisions prises, une décision exécutive contraignante a une puissance sans équivalent

Cas d’application réels

Migrations

• Il y a un an, les déploiements se faisaient manuellement environ 6 fois par semaine ; aujourd’hui, on est à 200 à 400 déploiements par semaine. L’effectif ingénierie n’a fait que doubler, mais la progression annuelle est de 20 à 30x ; deux personnes de l’équipe infra ont assuré 90 % de la refonte complète des pratiques de déploiement et de migration en deux mois
• Au 1er janvier, environ 25 % utilisaient chaque jour Claude Code ou Cursor ; fin février, c’était 100 %. Sans injonction top-down, grâce à l’amélioration de la qualité des outils et à des échanges avec les non-adoptants pour éliminer les frictions ; aujourd’hui, presque tous les PR ont leur premier jet rédigé par le harness
• Divers modes de configuration ont été unifiés en deux mécanismes de configuration (l’un pour les constantes client/serveur qui changent peu, l’autre pour les valeurs spécifiques au produit et fréquemment modifiées), sous forme de projets indépendants menés par des ingénieurs
  • Une personne a clarifié l’architecture → une autre a implémenté l’architecture de référence → plusieurs autres l’ont appliquée à d’autres zones ; cela aurait autrefois pris des années, mais a été terminé en moins d’un trimestre, y compris un outil interne de gestion des valeurs pour les équipes techniques et non techniques
• Le frontend multi-repo a été unifié en environ un mois dans une architecture monorepo ; 95 % du travail a été mené par un seul ingénieur frontend, ce qui a permis de disposer d’un harness frontend partagé et d’éliminer complètement l’hébergement de packages npm, source de frictions
• Un code frontend auparavant en grande partie non typé a été entièrement converti en typage statique, réalisé par un ingénieur sur plusieurs semaines avec un grand volume de tokens
• Pour de meilleurs paramètres de sécurité par défaut et des déploiements plus rapides, passage de npm à pnpm, mené par un ingénieur pendant quelques jours, quelques heures par jour

Le coût du code qui fonctionne dépend du harness de développement

• Envoyer « par-dessus le mur » des documents de conception ou des PR à des ingénieurs d’autres équipes ne produit aucun résultat ; des PR ou design docs bâclés sont peu coûteux, mais en réalité nuisibles
  • Ils exigent d’être réorganisés et corrigés, et ce contexte pollue les LLM au point de produire un résultat pire que repartir de zéro
• Quand un manager vérifie lui-même un changement, surveille les dashboards après déploiement et résout les problèmes éventuels, sa contribution directe au code est un grand succès ; sinon, elle n’a pas d’effet positif

Optimisation du cas standard des processus pour les agents

• Tous les tickets entrants de l’équipe opérations client sont triés par un harness qui connaît les équipes, les tickets ouverts et accède de façon limitée au data warehouse pour estimer l’impact ; cela traite plus vite un travail complexe, exigeant, mais peu intéressant
  • Les edge cases restent triés par des humains, et seuls certains jalons sont automatisés dans le même flux, sans changer le workflow humain
• La première passe de revue de code est effectuée par le même harness qui a implémenté le changement, mais avec le contexte de rédaction remis à zéro, ce qui permet aux humains de se concentrer sur des retours à plus forte valeur
• Le trimestre dernier, Claude Code et Cowork ont été déployés à l’échelle de l’entreprise ; l’équipe fraude a été particulièrement proactive pour remplacer du travail manuel par de l’automatisation de première passe, en automatisant l’investigation initiale d’attaques potentielles (y compris l’attribution fondée sur les données elles-mêmes)
• Migration de Jira vers Linear afin de renforcer l’infrastructure de workflows agent-first, grâce à un MCP plus puissant et une meilleure intégration Slack ; l’alpha d’un harness interne capable de récupérer des tickets depuis Linear et de les résoudre automatiquement est presque terminée

Équipes pérennes à forte ownership et contexte métier

• À l’arrivée de l’auteur, des personnes talentueuses tournaient rapidement d’un domaine à l’autre selon les projets, ce qui rendait l’organisation très réactive ; aujourd’hui, de petites équipes dédiées sont placées sur toutes les zones importantes pour investir dans la durée, et ce sont elles qui exploitent directement les nouvelles techniques d’IA
• Après le lancement de SierraAI, l’équipe l’a continuellement amélioré jusqu’à atteindre un niveau réellement excellent — un résultat impossible sans équipe dédiée et concentrée

Une prise de décision rapide, bonne et robuste

• Le changement de mode de configuration était controversé, ce qui a nécessité d’expliquer l’approche à plusieurs reprises ; l’impact variait selon les équipes, et les bénéfices n’apparaissaient qu’au niveau de l’écosystème (une seule personne configurant les paramètres de toutes les équipes), donc difficile à faire émerger par le bas
• La refonte du pipeline CI/CD était elle aussi controversée, car elle modifiait le modèle mental de déploiement et de release, en imposant une séparation explicite entre déploiement et release via le feature flagging
• L’unification en monorepo web était également une décision controversée, avec de grands bénéfices liés à une décision unifiée
• L’adoption de SierraAI a donné lieu à des discussions difficiles face aux concurrents et au scénario de non-adoption, et a nécessité une validation exécutive pour trancher les débats transverses

Conclusion

• Les cas ci-dessus ne sont qu’un échantillon représentatif parmi beaucoup d’autres ; le champ du possible continue de s’élargir chaque mois
• Ce qui freine reste globalement le même : désalignement organisationnel, manque de clarté, architecture technique défaillante