Ne commence pas par construire l'usine d'IA autonome

Voici une situation qui se produit en ce moment même dans les équipes d’ingénieurs. Un ingénieur passe son week-end à faire tourner quatre ou cinq agents de codage en parallèle. Le lundi matin, un collègue ouvre son ordinateur portable et tombe sur 53 fichiers modifiés avec plus de 2 000 différences, accompagnés d’un message qui dit en gros : « Ça devrait être bon à fusionner. » Personne n’a demandé un tel volume de travail. Personne n’a le temps de le relire correctement. L’équipe n’a pas l’impression d’aller plus vite. Elle a l’impression de se faire prendre au dépourvu.

C’est ce qui arrive quand la productivité individuelle de l’IA devance la préparation de l’équipe, et c’est la plainte la plus fréquente qu’on a entendue lors de nos discussions avec les personnes qui développent Upsun Dispatch™. C’est pourquoi l’adoption de l’IA doit se faire dans l’ordre, étape par étape, et le modèle de maturité en huit étapes de Fabien Potencier est la feuille de route la plus claire pour comprendre à quoi ressemble réellement cet ordre.

Les équipes qui passent directement du vide à l’usine autonome finissent par être épuisées, exposées, voire les deux. Celles qui en tirent une vraie valeur franchissent toutes les étapes intermédiaires. Voilà pourquoi cet ordre est important.

Ces étapes constituent une succession de problèmes de confiance.

Fabien Potencier, CTPO chez Upsun et le cerveau derrière Symfony, l’explique simplement : il faut passer par chaque étape de l’adoption de l’IA pour comprendre pourquoi la suivante existe. 

Son modèle va du « vide » (étape 1), où l’utilisation de l’IA ne repose sur aucune stratégie réelle, en passant par la « dérive », les « îlots », le « pari sur la standardisation », la « refonte des processus » et le « système d’exploitation », jusqu’à l’« usine lumineuse » (étape 7), où les ingénieurs supervisent un essaim croissant d’agents fonctionnant localement, et enfin l’« usine autonome » (étape 8), où les agents tournent sur une infrastructure partagée et où le travail consiste désormais à gérer le système plutôt que le code.

Chaque étape ne se résume pas simplement à « plus d’IA ». C’est un problème différent : à quel point tu fais confiance au résultat, à quel point tes systèmes sont exposés, et dans quelle mesure le travail reste cohérent dès que plusieurs personnes y mettent la main. Tu ne résous pas le pari de la standardisation (étape 4), où la direction s’engage à mettre en place des outils et une gouvernance partagés, en installant ces outils au sein d’une équipe encore coincée dans la dérive (étape 2), où le processus de chacun n’existe que dans sa propre tête. Ce n’est pas l’outil qui instaure la confiance. C’est l’équipe qui le fait, en franchissant les étapes qui la construisent.

La scène du lundi matin décrite plus haut, c’est à ça que ressemble l’« usine brillante » (étape 7) quand personne n’a pris les habitudes que les étapes précédentes étaient censées inculquer.

Ce qui ne fonctionne plus quand tu sautes des étapes

On a entendu les trois mêmes schémas d’échec de la part de plusieurs personnes, indépendamment les unes des autres, ce qui est généralement le signe qu’on a mis le doigt sur quelque chose de concret plutôt que sur la théorie favorite d’une seule personne.

1. La dette de sécurité s’accumule en silence. Patrick Dawkins, ingénieur logiciel principal chez Upsun, qualifie le risque principal lié aux agents non supervisés de « trio mortel » : des données non fiables, des actions réelles et des informations privées, toutes accessibles en même temps. Les équipes repèrent ça tôt, en vérifiant chaque commande. Mais cette vigilance s’estompe à mesure que les validations deviennent répétitives et que les gens commencent à cliquer sans lire, bien avant que quiconque ne décide de désactiver ce processus.
2. La dette technique s’accumule plus vite que les équipes ne le pensent. C’est un schéma qui est revenu plus d’une fois dans nos discussions : un projet qui, auparavant, accumulait cinq ans de dette avant de devoir être réécrit, atteint désormais ce seuil en six mois.
3. La productivité d’une personne devient le goulot d’étranglement de tout le monde. C’est le scénario du lundi matin évoqué plus haut. Les gains liés à l’exécution d’agents sont individuels. Un ingénieur seul peut vraiment en faire plus. Mais confie le travail de ce même ingénieur à une équipe de trois ou quatre personnes qui n’a pas mis en place de processus commun pour examiner le travail généré par les agents, et le rendement global de l’équipe peut stagner, voire baisser. 

L’autonomie se mérite, elle ne s’active pas d’un simple clic

Si sauter des étapes est le mode d’échec, le « cadran de confiance » est le mécanisme qui l’empêche. Les agents gagnent leur autonomie de la même manière qu’un nouvel employé. Au début, chaque action importante doit être vérifiée par un humain. 

Au fil des semaines, à mesure qu’un processus spécifique fait ses preuves encore et encore, le contrôle humain sur ce processus est levé, et l’agent passe à des tâches moins étroitement supervisées. La confiance n’est pas accordée d’emblée. Elle se gagne séparément pour chaque processus plutôt que d’un seul coup pour l’« IA » en général.

Pour l’instant, les modèles sont juste assez lents pour qu’un humain puisse suivre, mais ça ne durera pas. Le but de cette confiance par étapes n’a jamais été de faire en sorte que les humains continuent à vérifier indéfiniment. C’est pour s’assurer que l’autonomie qui finira par remplacer cette vérification a bien été méritée, et non pas simplement ignorée.

Ces étapes s’appliquent peu importe où une équipe commence

On pourrait facilement interpréter ça comme « il te faut une équipe mature avant que l’IA vaille la peine d’être utilisée ». Ce n’est pas l’argument. Les équipes qui partent de zéro (étape 1) peuvent et doivent se lancer. Ce qui ne marche pas, c’est de sauter les étapes qui te permettent de développer les compétences qu’une étape ultérieure suppose que tu possèdes déjà.

Commencer délibérément dans le vide vaut mieux que de se lancer tête baissée dans le pari de la standardisation (étape 4) en espérant que les processus se mettent en place tout seuls. Si ton équipe en est encore là, commence délibérément, non pas parce que tu n’as pas encore atteint la refonte des processus (étape 5), mais parce que c’est dans le vide que tu développes les habitudes de révision que cette étape suppose que tu possèdes déjà.

La preuve, avec l’équipe qui a développé Upsun Dispatch™

Upsun Dispatch a été développé à l’aide d’une première version de lui-même, et cette première version a justement mis en évidence le genre de problèmes qu’une adoption par étapes est censée détecter. La première version du processus de révision des pull requests regroupait tous les retours dans un seul et même commentaire. 

Il a fallu mettre le processus en pratique, et pas seulement le concevoir sur le papier, pour se rendre compte que ça rendait les revues plus difficiles à utiliser, et non l’inverse. Il a été refait pour que les commentaires apparaissent en ligne, à côté du code auquel ils se rapportent. Ce déploiement par étapes ne se contente pas d’éviter les catastrophes ; il met en évidence les erreurs courantes qui n’apparaissent qu’une fois que le travail réel passe par le système.

Où ça te mène

Tout ça ne veut pas dire qu’il faut attendre. Ça veut dire qu’il faut y aller dans l’ordre.

Si tu fais déjà tourner des agents en parallèle et que tu commences à te retrouver dans le scénario du lundi matin décrit plus haut, ce n’est pas le moment d’ajouter encore plus d’automatisation. C’est le moment de revenir en arrière d’une étape et de mettre en place le processus partagé que tu as sauté.

Les équipes qui réussissent ça ne seront pas celles qui auront atteint l’usine autonome en premier. Ce seront celles qui pourront montrer chaque étape qu’elles ont franchie pour y arriver.

Pour avoir une vue d’ensemble, Fabien Potencier a répertorié les huit étapes, de l’habitude individuelle à l’habitude organisationnelle, dans un article séparé.

• Tu es nouveau ici ? Lis l’introduction à Upsun Dispatch.
• Tu veux contribuer à son développement ? Postule pour rejoindre la promotion des partenaires fondateurs en design.