Le nouvel ingénieur 10x n’écrit pas 10 fois plus de code. Il construit le système qui l’écrit.

L’ingénieur 10x a été un mythe de la Silicon Valley pendant des décennies. Le génie solitaire, les écouteurs sur les oreilles, produisant du code élégant à une vitesse surhumaine. Nous avons débattu de son existence, argumenté sur la façon de les embaucher et ressenti secrètement de la rancœur envers quiconque prétendait en être un.

Mais quelque chose d’intéressant s’est produit sur le chemin de l’avenir axé sur l’IA : l’ingénieur 10x est devenu réel. Il ne ressemble toutefois pas à ce que nous avions imaginé.

OpenAI a récemment partagé comment une équipe de trois personnes a utilisé Codex pour expédier 1 500 demandes d’extraction et environ un million de lignes de code, sans écrire une seule ligne manuellement. Trois ingénieurs, et zéro code écrit à la main. Un produit de production utilisé par des centaines d’utilisateurs internes.

Ce n’est pas 10 fois plus ; c’est plutôt 100 fois plus. Et la compétence qui a rendu cela possible n’était pas de taper plus vite ou de connaître plus d’algorithmes. C’était de construire le système qui rend les agents IA productifs : les flux de travail, les garde-fous, les boucles de vérification, les interfaces que les agents se connectent et que les humains examinent.

Je crois que c’est l’émergence d’une nouvelle fonction clé dans les organisations d’ingénierie. J’appellerais cela l’ingénierie d’orchestration IA.

Trois disciplines entrent dans un standup

Si vous regardez ce qu’un ingénieur d’orchestration IA fait réellement, vous reconnaîtrez trois disciplines familières fusionnées en une.

Le ingrédient le plus évident est DevOps. DevOps a centralisé le pipeline de déploiement. Une équipe a configuré les flux de travail CI/CD que chaque ingénieur utilisait lors de l’expédition du code. L’ingénierie d’orchestration IA fait la même chose, mais pour les flux de travail des agents. Elle définit comment les tâches sont attribuées aux agents, comment les sorties sont validées, comment les réessais et les sauvegardes fonctionnent. C’est l’infrastructure partagée sur laquelle les agents s’exécutent.

Ensuite, il y a l’architecture, qui se chevauche avec DevOps plus que vous ne le pensez. Les architectes décident quelles interfaces sont verrouillées, quels modèles sont appliqués, quels limites ne peuvent pas être franchies. Dans un monde axé sur les agents, cela compte encore plus. Les agents ont besoin de bases de code propres et bien documentées avec des contrats clairs. L’ingénieur d’orchestration IA définit ces contraintes, pas seulement pour la lisibilité humaine, mais pour la compréhension des agents. Un référentiel désorganisé n’est pas seulement une dette technique. C’est un plafond de productivité pour chaque agent qui le touche.

La partie la moins comprise est la couche spécifique à l’IA. L’ingénierie de prompt, la gestion du contexte, la sélection de modèles, la configuration des agents. Aujourd’hui, la plupart des ingénieurs font cela de manière éparse, tâche par tâche. Chaque personne découvre son propre style de prompt, son propre réglage d’agent, ses propres solutions de contournement. L’ingénieur d’orchestration IA centralise cela. Il construit les cahiers de jeux partagés, les configurations réutilisables, les connaissances organisationnelles sur ce qui fonctionne et ce qui ne fonctionne pas sur les modèles et les cas d’utilisation.

Séparément, ces trois fonctions existent dans la plupart des organisations d’ingénierie aujourd’hui. L’argument est que les combiner en un seul rôle centralisé crée quelque chose de qualitativement différent.

La métaphore du showrunner

Un réalisateur de film n’opère pas la caméra, n’agit pas dans les scènes ou n’édite les rushes. Mais chaque cadre reflète ses décisions.

Il choisit la composition du plan, le rythme, le ton. Il décide quand pousser et quand reculer. Il met en place l’environnement (éclairage, conception de plateau, blocage) de telle sorte que chaque personne sur le plateau puisse faire son meilleur travail dans une vision cohérente. L’équipe est individuellement talentueuse, mais sans cette coordination, vous obtenez un désordre qui ne sera jamais expédié.

L’ingénierie d’orchestration IA fonctionne de la même manière. Les agents sont capables. Les modèles sont puissants. Mais sans quelqu’un qui conçoit le système qui les coordonne, définit les contraintes, construit les boucles de rétroaction, structure les flux de travail, vous obtenez ce que nous avons tous vécu : des sorties incohérentes, des ressources informatiques gaspillées, des agents travaillant à des fins contraires, et des ingénieurs passant plus de temps à corriger le code généré par l’IA qu’ils ne l’auraient fait en l’écrivant eux-mêmes.

Le réalisateur rend le film supérieur à la somme de ses parties. L’ingénieur d’orchestration IA fait la même chose pour les flottes d’agents.

Pourquoi la plupart des organisations sous-investissent

Voici ce que je vois dans l’industrie : les entreprises investissent lourdement dans les outils IA et pas assez dans les systèmes qui les entourent.

Les ingénieurs ont accès à Copilot, Claude, Codex. Ils expérimentent individuellement. Certains deviennent des utilisateurs avancés. La plupart atteignent un plateau au stade de l’« autocomplete de luxe ». Les gains de productivité de 20 % que les études signalent toujours ? C’est le symptôme de l’adoption d’outils sans réflexion au niveau du système.

Les organisations qui cassent les codes, celles qui rapportent une productivité deux fois ou plus supérieure, ont quelque chose en commun. Elles ont centralisé le travail d’orchestration. Quelqu’un (ou une équipe) possède les flux de travail des agents, la préparation du référentiel, l’infrastructure de vérification, le contexte partagé que chaque agent peut accéder.

À quoi ressemble réellement le rôle

La journée d’un ingénieur d’orchestration IA peut inclure :

• Concevoir des flux de travail d’agent : définir comment une demande de fonctionnalité devient une spécification, devient un plan, devient des tâches d’agent parallèles, devient du code examiné et fusionné.
• Construire une infrastructure de vérification : des tests automatisés, des règles de linting, des analyses de sécurité et des cadres d’évaluation que les agents doivent passer avant que leur travail ne soit fusionné.
• Maintenir la santé du référentiel pour la consommation des agents : documentation, interfaces claires, gestion des dépendances et simplification du code, le tout optimisé pour la compréhension des agents, et non seulement pour la lisibilité humaine.
• Centraliser les stratégies de prompt et de contexte : des invites de système partagées, des pipelines de récupération, des décisions de routage de modèle et des modèles de configuration que l’équipe entière utilise.
• Surveiller et améliorer les performances des agents : suivre les taux de réussite, les modes d’échec, le coût par tâche et le temps de fusion à travers la flotte d’agents, puis ajuster le système en fonction des données.

Cette personne siège à l’intersection de l’ingénierie de plateforme, de l’architecture logicielle et de l’expertise en IA. Elle n’écrit pas de fonctionnalités. Elle construit le système qui rend la livraison de fonctionnalités rapide, fiable et évolutivité.

Le modèle historique

Aux débuts du cloud computing, le déploiement était la quête secondaire de chaque ingénieur. Chaque équipe avait ses propres scripts, ses propres configurations de serveur, sa propre façon d’obtenir le code en production. DevOps est apparu pour centraliser ce travail, et l’ingénierie de plateforme a évolué pour le construire en une infrastructure autonome et partagée.

L’IA suit la même trajectoire. Actuellement, l’utilisation des agents est la quête secondaire de chaque ingénieur. Chaque personne a son propre style de prompt, ses propres préférences d’outils, son propre modèle mental pour savoir quand l’IA aide et quand elle ne l’aide pas. Les organisations qui centralisent cela, qui le traitent comme une infrastructure et non comme une expérimentation individuelle, prendront les devants de la même manière que les organisations avec des pratiques DevOps matures ont distancé celles qui n’en avaient pas.

La différence est la vitesse. La transition DevOps a pris une décennie. Celle-ci pourrait prendre des trimestres. Même si je suppose que les organisations reconnaissent le modèle plus rapidement qu’elles ne le font habituellement.

La voie à suivre

Si vous êtes un dirigeant d’ingénierie, voici ce que je vous suggère, même si votre parcours peut varier en fonction de l’état actuel de votre équipe.

1. Identifiez qui fait déjà ce travail de manière informelle. Chaque organisation a quelqu’un qui a découvert les flux de travail des agents, que d’autres ingénieurs consultent pour obtenir des conseils sur les invites ou la configuration des outils. Cette personne est votre ingénieur d’orchestration IA proto.
2. Rendez-le explicite. Donnez à la fonction un nom, un mandat et des ressources. Ne laissez pas cela rester un projet secondaire attaché au « vrai » travail de quelqu’un.
3. Commencez par la préparation du référentiel. Avant d’investir dans des flux de travail d’agent sophistiqués, assurez-vous que votre base de code est quelque chose que les agents peuvent réellement parcourir. Interfaces claires, bonne documentation, tests complets, architecture simplifiée.
4. Centralisez ce qui fonctionne. Lorsqu’une personne découvre une stratégie de prompt ou un modèle de flux de travail qui améliore considérablement la sortie des agents, captez-le. Faites-en la valeur par défaut pour toute l’équipe, et non une connaissance tribale verrouillée dans la tête de quelqu’un.
5. Mesurez au niveau du système. Ne suivez pas seulement l’utilisation individuelle des outils. Suivez combien de tâches les agents complètent de bout en bout, à quoi ressemblent les taux d’examen et de révision, où se trouvent les goulets d’étranglement.

Le nouvel ingénieur 10x

Le mythe de l’ingénieur 10x a toujours été axé sur l’héroïsme individuel. Une personne, surpassant tout le monde par un talent et une caféine pure.

La réalité de l’ingénieur 10x à l’ère de l’IA est axée sur la pensée système. La personne qui rend chaque autre ingénieur (et chaque agent) plus productif en construisant les bonnes infrastructures, les bons flux de travail, les bonnes contraintes.

Il n’écrit pas 10 fois plus de code. Il construit le système qui l’écrit.

Je ne suis pas certain que ce rôle se cristallisera exactement comme je l’ai décrit ici. Mais je suis assez sûr que les organisations qui comprennent la couche d’orchestration (quel que soit le nom qu’elles lui donnent) seront celles qui réalisent réellement les gains de productivité dont tout le monde parle.