*Partie 1 sur 5 dans la série [The Human Inversion](/posts/series/the-human-inversion). Suivant : [Le plafond d'attention](/posts/l'inversion-humaine-le-plafond-d'attention)*

---

## Points clés à retenir

- Les équipes s'organisaient autour de **l'exécution** (spec → design → code) ; **foundation** et **review** étaient chroniquement sous-alimentés parce que le calendrier se dirigeait vers le milieu.
- Lorsque l'IA absorbe la production d'artefacts au milieu, **les humains se concentrent aux extrémités** : un positionnement, des systèmes et une architecture plus riches d'un côté ; d'autre part, des contrôles plus approfondis de la qualité et de l'ajustement.
- La suppression du milieu humain supprime la **traduction implicite** qui permettait de maintenir l'alignement des disciplines ; La **cohérence interdisciplinaire** doit alors vivre dans des normes explicites, des artefacts durables et un jugement aux extrémités, et non dans des transferts de couloir.
- L'inversion est **économiquement forcée**, et non facultative — mais elle met à rude épreuve les spécialistes dont la crédibilité était liée au métier d'exécution jusqu'à ce que le jugement soit à nouveau rendu lisible.
- **Agents-in-a-loop** (travail d'agent asynchrone côté serveur) est à quoi ressemble l'absorption du milieu au niveau du système ; L’IA synchrone uniquement maintient les humains au milieu en tant que déclencheur de chaque étape d’exécution.

Pendant la majeure partie de l’histoire du développement logiciel, les humains ont passé la plupart de leur temps au milieu.

Divisez le processus en trois parties :

1. Fondation : l'étude de marché, le positionnement et la définition de la personnalité qui précèdent toute fonctionnalité ; les systèmes de conception et les contraintes qui régissent la façon dont les interfaces sont construites ; les normes architecturales et les conventions de codage qui façonnent ce que l'ingénierie peut même envisager.
2. Exécution : transformer ces fondations en véritables artefacts : les spécifications deviennent des conceptions, les conceptions deviennent du code, le code devient un logiciel livré.
3. Révision : le peaufinage, les tests, le travail minutieux pour s'assurer que ce qui a été produit répond réellement aux normes et fonctionne réellement pour les humains qui doivent l'utiliser - et, surtout, l'apprentissage qui met à jour vos priorités pour la prochaine fois.

Les équipes étaient organisées autour du milieu. Les responsables du produit ont rédigé les spécifications. Les concepteurs ont mis en œuvre les spécifications sous forme de conceptions. Les ingénieurs ont implémenté les conceptions sous forme de code. Même les méthodologies Lean, qui tentaient explicitement de transformer la cascade en quelque chose de plus collaboratif et interdisciplinaire, ne parvenaient toujours pas à sortir la plupart des humains de cet espace intermédiaire.

Les transferts ont été porteurs. La coordination était porteuse. Les dépendances séquentielles étaient porteuses. Un concepteur pouvait effectuer un travail exploratoire avant que les spécifications du produit ne soient finalisées, et un ingénieur pouvait effectuer des recherches avant que les conceptions ne soient verrouillées, mais les artefacts réels (ceux qui ont été expédiés) nécessitaient que les résultats de la discipline précédente soient pratiquement complets avant que la discipline suivante puisse faire du bon travail.

Cela a eu des conséquences aux deux extrémités :

**La Fondation a récupéré ce qui restait.** Les études de marché ont été réalisées en marge, entre le véritable travail de rédaction des spécifications. Les systèmes de conception ont été construits de manière réactive, rassemblés après coup à partir de modèles apparus sur les écrans expédiés. Les normes de codage vivaient dans des wikis que personne ne lisait et les décisions architecturales s'accumulaient sous forme de connaissances tribales parce que personne n'avait le temps de les écrire. La fondation était le lieu où vivait l’effet de levier, mais l’exécution dévorait le calendrier, donc la fondation recevait toute l’attention qui survivait.

**La révision a été moins bien traitée.** Le contrôle qualité était une phase à la fin d'un sprint si vous aviez de la chance, ou un ticket dans le backlog de quelqu'un si vous ne l'étiez pas. La révision de la conception était un fil de discussion Slack. La révision du code était un rituel optimisé pour le débit, et non pour détecter les éléments qui comptaient réellement. Les détails qui séparent les logiciels qui fonctionnent des logiciels qui ravissent ont été traités dans les derniers 10 % de la chronologie, ce qui correspond exactement au moment où tout le monde était le plus fatigué et le plus sous pression pour expédier.

Ce n’était pas un choix fait par les équipes. C’était un équilibre imposé par l’économie. Lorsque l'exécution était coûteuse, il fallait confier l'exécution au personnel, ce qui signifiait que la fondation et la révision recevaient le temps et l'attention qui restaient. Waterfall et Lean n'étaient pas sous-optimaux aux extrémités parce que les équipes ont choisi de les négliger. Ils étaient limités en liquidités.

Ensuite, l’IA a changé l’économie.

Le milieu – la production réelle d’artefacts – est celui où l’IA et les harnais puissants sont véritablement efficaces à l’heure actuelle. Vous n'avez pas besoin d'un responsable produit pour rédiger les spécifications, d'un concepteur pour transformer les spécifications en conception et d'un ingénieur pour transformer la conception en code, chaque transfert consommant des jours de réunions de synchronisation et de traduction du contexte. Vous avez besoin d’un humain qui sait ce qui devrait exister et d’un modèle capable de le produire.

Le coût d'exécution s'est effondré. Pas jusqu’à zéro, et pas uniformément dans tous les domaines, mais suffisamment pour que le centre gravitationnel où se déroule le travail humain se soit déplacé.

L’infrastructure a évolué parallèlement à l’économie. Le modèle transitoire est celui de l'humain : une personne au centre de chaque étape d'exécution, déclenchant chaque action, examinant chaque résultat, maintenant le tempo. Ce qui émerge, ce sont des agents en boucle : les serveurs exécutant l'agent fonctionnent en continu et de manière asynchrone, les humains définissant la direction et examinant les résultats plutôt que de diriger chaque étape. L'humain dans le circuit maintient les gens au milieu. Agents-in-a-loop, voilà à quoi ressemble l’absorption du milieu au niveau du système.

## Les humains vont désormais jusqu'au bout

Côté fondation :

- Le produit peut consacrer du temps à ce que le travail produit a toujours été censé être : une étude de marché approfondie, un positionnement sérieux, des personnalités validées, une réflexion approfondie sur les garanties et les avantages qui sont importants et pourquoi. Pas sur l'écriture de spécifications qui sont traduites en conceptions qui sont traduites en code.
- Le design peut consacrer du temps aux systèmes de conception, aux contraintes et aux décisions transversales qui déterminent la cohérence d'une centaine d'écrans futurs. Pas sur le fait de remettre les pixels de Figma à un ingénieur.
- L'ingénierie peut consacrer du temps aux normes architecturales, aux principes qui déterminent quelles classes de bogues sont possibles et lesquelles sont structurellement exclues, aux décisions de plate-forme qui s'aggraveront au fil des années. Pas sur la conversion des tickets en pull request.

Du côté de l’évaluation, chaque discipline peut consacrer beaucoup plus de temps aux questions qui ont toujours compté mais qui ont rarement reçu une réponse approfondie :

- Cela résout-il réellement le problème de l'utilisateur, ou résout-il un problème que le modèle a mal déduit ?
- Est-ce que cela correspond réellement au système de conception, ou s'agit-il d'un cas isolé qui créera une incohérence ?
- Ce code respecte-t-il réellement les contraintes architecturales, ou est-ce un raccourci qui va composer ?

La charge de révision n’est pas uniforme sur toutes les surfaces. Sur la plupart des codes, une révision approfondie améliore la qualité. Sur les surfaces où l'échec est catastrophique – code de pont dans l'infrastructure cryptographique, aide à la décision clinique, contrôles aérospatiaux, rails de paiement – ​​l'extrémité de l'examen devient le tiers limitant le débit du pipeline, supportant l'essentiel de la charge de qualité. L'architecture s'applique toujours ; le poids se déplace.

C'est l'inversion : **les humains aux extrémités, l'IA au milieu.** Et c'est désormais aux extrémités que l'effet de levier se différencie, car le *coût* d'exécution devient un enjeu de table, même si sa *qualité* détermine toujours l'intensité avec laquelle la fin de l'examen doit travailler. Avant, nous ne pouvions tout simplement pas nous permettre de recruter correctement du personnel aux extrémités, car l'exécution dévorait tout le monde.

Exprimée de cette façon, l’inversion semble être un pur avantage. Plus de temps pour la fondation, plus de temps pour la révision, moins de frictions de transfert, moins de taxes de coordination. Et c'est *c'est* un avantage : un avantage substantiel, le plus grand changement de productivité que les équipes logicielles aient connu en une génération.

## À quoi ressemble la transition de l'intérieur

L’architecture est nette positive. L’expérience de la traverser n’est pas uniforme, et tout récit honnête de l’inversion doit dire ce qui arrive réellement aux spécialistes qui se trouvent au centre de celle-ci.

Les personnes qui ont été définies par leur savoir-faire d'exécution – celles dont la réputation s'est bâtie sur l'écriture de bon code, la production de conceptions épurées, la rédaction de spécifications strictes – regardent ce pour quoi ils ont été embauchés se laisser absorber. Les compétences ne sont pas devenues inutiles. Le jugement, le goût, la connaissance du domaine, l'intuition du système, l'instinct selon lequel la simplicité coûte cher et ce qui coûte cher – rien de tout cela n'est encore automatisé, et la plupart ne le seront pas bientôt.

Mais la compétence *d’accréditation*, ce qui les a amenés à entrer dans la salle, diminue. Ce qui reste est plus difficile à valoriser à court terme pour le marché, car le marché n'a pas développé le vocabulaire nécessaire pour le valoriser indépendamment de l'exécution à laquelle il était auparavant attaché.

Cela se manifeste de manière spécifique. Les ingénieurs à mi-carrière des équipes à forte intensité d'IA se demandent de plus en plus s'ils devraient passer à la gestion de produits - non pas parce que le travail de PM est leur passion, mais parce que le PM est un rôle défini par le jugement et la communication, et que le jugement et la communication sont des compétences qui ne se sont pas simplement atrophiées. Le mouvement est souvent dans la bonne direction. La forme que cela prend dans la conversation : « mon travail n'a plus d'importance, alors puis-je devenir chef de produit ? – est la forme d’une réponse rationnelle à une transition illisible, et non d’un pur enthousiasme pour un nouveau rôle.

La confusion inverse est tout aussi courante : on se tourne vers la compétence que l’IA vient de rendre accessible plutôt que vers celle qu’elle a rendue rare.

L'inversion n'invalide pas les spécialistes qui le ressentent. Au contraire, cela dépend d'eux : la fondation et la révision sont les points de levier de la nouvelle architecture, et toutes deux reposent exactement sur le jugement et le goût que les spécialistes de l'ère de l'exécution ont passé quinze ans à accumuler.

Ce qu'il faut, c'est changer la façon dont ce jugement est rendu lisible, tant pour les spécialistes eux-mêmes que pour les organisations qui tentent de les évaluer. Le marché ne dispose pas encore d'un bon vocabulaire pour évaluer le jugement indépendamment de l'exécution avec laquelle il était auparavant associé. Construire ce vocabulaire - à travers des rubriques, à travers de nouveaux critères d'évaluation, à travers une conversation honnête sur ce qu'est réellement le rôle actuel - fait partie de la façon dont la transition cesse de ressembler à une perte et commence à ressembler à un levier.

L'exécution est d'abord automatisée. Ce n’est pas le cas du jugement. La majeure partie de cette série porte sur ce qu'il faut faire pour doter le personnel et organiser correctement le jugement une fois que l'exécution n'est pas la porte.

## Le problème que l'ancienne organisation n'avait pas

Lorsque l’exécution se situait au milieu et que les humains remettaient les artefacts entre les disciplines, la coordination se faisait à travers les artefacts eux-mêmes. La spécification a forcé le PM et le concepteur à s'aligner car le concepteur devait la lire. La revue de conception a forcé le concepteur et l'ingénieur à s'aligner car l'ingénieur devait construire à partir de celle-ci. Le milieu était celui où le contexte interdisciplinaire était transmis, car la traduction se produisait en temps réel alors que les humains produisaient réellement la chose ensemble. C'était lent, frustrant et plein de gaspillage, mais cela a bien fait une chose : cela a permis de garder les disciplines en contact les unes avec les autres.

Retirez le milieu et ce contact va avec.

Les spécialistes travaillant aux extrémités ne comprennent pas automatiquement le travail de chacun :

- Le document de positionnement du PM est illisible pour l'ingénieur.
- Le document de contraintes du concepteur est illisible pour le PM.
- Les normes architecturales sont illisibles pour le concepteur.

Chaque discipline produit des artefacts fondamentaux qui, dans l’ancien modèle, n’avaient jamais besoin d’être lisibles de manière croisée, car un humain au milieu effectuait la traduction en temps réel. Maintenant, il n'y a plus d'humain au milieu. Il y a l’IA au milieu, qui est excellente pour produire l’artefact mais ne résout pas intrinsèquement les tensions interdisciplinaires qui étaient autrefois résolues au fil des réunions et des transferts.

La question à laquelle le reste de cette série doit répondre est donc la suivante : comment le travail parallèle asynchrone des spécialistes fonctionne-t-il réellement sans sombrer dans l'incohérence ? Quelle couche remplace la coordination que le milieu transportait auparavant ? Qui crée le contexte partagé et comment reste-t-il fiable au fil du temps ?

## La réclamation

Voici la réponse que je développerai dans les trois prochains articles, énoncée sans détour afin qu'elle puisse être testée :

> Les équipes qui ne se restructurent pas autour de l'inversion auront un aspect considérablement pire d'ici dix-huit mois, et la plupart des équipes ne se restructureront pas – non pas parce que le changement technique est difficile, mais parce que le changement culturel est plus difficile que ce que l'on pense actuellement.

Le changement culturel nécessite des choses que la plupart des organisations trouvent véritablement inconfortables :

- Les dirigeants rédigent des rubriques commerciales qu'ils ont historiquement gardées volontairement floues.
- Des spécialistes trouvant leur identité professionnelle dans le goût et le jugement plutôt que dans le savoir-faire d'exécution.
- Abandonner les réunions qui fonctionnent actuellement comme la preuve visible de la coordination des équipes et faire confiance à des mécanismes asynchrones avec lesquels personne n'a des années d'expérience.
- Embaucher sur un déclencheur différent de celui que de nombreux investisseurs et manuels d'exploitation approuvent actuellement.

Rien de tout cela n’est impossible. Une partie de cela se produit déjà. Mais les équipes qui le découvriront en premier cumuleront des avantages que les équipes qui tardent ne pourront pas facilement combler, car la combinaison se produit au niveau de la couche de base et de la couche de révision – les couches qui ont toujours été censées compter le plus et que la plupart des équipes n'ont jamais été en mesure de doter correctement en personnel.

Les équipes qui s’en sortiront bien seront également celles qui reconnaîtront à quel point la transition est inconfortable pour les spécialistes qui se trouvent au centre de celle-ci, plutôt que de prétendre que cet inconfort ne fait pas partie du système. Un changement qui est bon pour l'organisation ne fait pas automatiquement du bien à la personne qui s'y trouve, et traiter l'écart comme un échec d'attitude plutôt que comme une caractéristique structurelle est la façon dont une architecture par ailleurs correcte perd les personnes dont elle a le plus besoin.

[Le prochain article](/posts/the-human-inversion-the-attention-ceiling) concerne le déclencheur d'embauche. Quand ajoute-t-on réellement un humain à une équipe dont l’exécution est gérée par l’IA ? La réponse n’est pas celle que suggère la sagesse actuelle des startups, et se tromper est l’erreur la plus coûteuse disponible dans cette transition.

---

*Continuer la lecture : [Partie 2 — Le plafond d'attention](/posts/the-human-inversion-the-attention-ceiling)*