Le « trust dial » de l’IA : des agents locaux à l’usine logicielle autonome

On parle beaucoup de l'utilisation de l'IA, notamment de la façon dont les équipes d'ingénieurs l'intègrent dans leurs processus de codage. Le travail manuel est remplacé par une automatisation pilotée par des agents, et la valeur humaine réside de plus en plus dans les tâches de haut niveau : rédiger des cahiers des charges, réfléchir à l'architecture, définir la direction à suivre, faire preuve de bon goût et valider le résultat.

Dans ce contexte, les débats incessants autour du choix des modèles, de la productivité et des indicateurs clés de performance (KPI) ne sont qu’une partie d’une question plus large : dans quelle mesure peut-on se fier aux résultats générés ? Et que peux-tu faire dès le départ pour avoir davantage confiance par défaut ?

Fabien Potencier, cofondateur et CTPO d’Upsun, réfléchit à ce problème depuis longtemps. Ayant observé le secteur traverser plusieurs vagues d’adoption de l’IA, de la saisie semi-automatique aux copilotes en passant par les agents fonctionnant dans le cloud, il a vu la même tension émerger à chaque étape : le fossé entre ce qu’un agent est capable de faire et ce qu’une équipe se sent réellement à l’aise de le laisser faire sans supervision.

Pourquoi faut-il se concentrer sur la confiance ?

Quand un agent prend des mesures qui ont de réelles conséquences, soit les humains supervisent tout de manière excessive et mécanique, en approuvant des actions qu’ils ne lisent même plus, soit ils tombent dans l’extrême opposé : ce que Fabien Potencier appelle le « mode yolo », c’est-à-dire abandonner complètement la supervision et laisser l’agent faire ce qu’il veut par défaut.

Il le décrit très bien : « Au début, tu ne fais pas confiance aux LLM. Tu veux rester dans la boucle pour t’assurer de pouvoir valider tout ce que fait l’agent. » Mais tout valider peut vite devenir un véritable boule de neige si tu n’établis pas d’abord un contexte partagé, des compétences bien définies et des limites claires, ce qui te fait te retrouver face aux mêmes problèmes encore et encore.

Dans ce scénario, la confiance, c’est tout le contexte que tu construis au fil du temps : donner à l’agent une bonne compréhension de ce que tu veux faire et de la manière dont tu veux le faire, pour qu’il puisse mériter l’autonomie qui lui est accordée. C’est ce travail délibéré de construction des fondations qui rend possible une autonomie significative, et qui est la condition préalable à tout ce qui viendra ensuite.

Alors, peut-on passer d’une supervision totale à une autonomie significative sans compromettre la qualité, ni la maintenabilité à long terme, ni la sécurité de ce qui est produit ?

C’est un cadran, pas un interrupteur

Pour expliquer ça, Fabien Potencier utilise la métaphore suivante : la confiance, c'est un cadran, pas un interrupteur. Un interrupteur, c'est binaire : marche ou arrêt, supervisé ou autonome. Un cadran, en revanche, est gradué ; il bouge par paliers.

Au début, le cadran est tourné à fond vers la supervision humaine, ce qui veut dire que chaque action nécessite une validation et une vérification. À ce stade, chaque décision implique un humain dans la boucle et, au fur et à mesure que les résultats s’accumulent, le cadran peut tourner progressivement.

« La confiance se gagne parce que tu as fait le travail », explique Fabien Potencier, « et à un moment donné, tu peux supprimer certaines barrières parce que tu es sûr que ça va bien se passer à chaque fois. »

Mais cette confiance ne vient pas du simple fait que l’agent répète la même tâche plusieurs fois. Il faut que l’humain effectue un travail de rétrospective après chaque exécution : donner du feedback, ajuster les invites, affiner les compétences, pour que ce qui a été appris soit intégré au processus lui-même.

L’objectif est de transférer progressivement tout ce qui peut être rendu déterministe vers des scripts et des compétences qui fonctionnent de la même manière à chaque fois. Une fois que quelque chose est intégré, tu ne comptes pas sur l’agent pour qu’il le redécouvre ; tu fais confiance à un processus que tu as construit et dont tu sais qu’il tiendra la route.

L’humain prend du recul, non pas parce qu’il a été remplacé, mais parce qu’il a mis en place suffisamment de garde-fous et encodé suffisamment de parties du processus pour savoir quand son attention est réellement nécessaire et quand elle ne l’est pas.

Le vrai défi

Ce changement semble assez simple, mais la difficulté n’est pas technique ; elle est comportementale. La plupart des équipes ont du mal à faire bouger les choses, tout simplement parce qu’elles ne font pas confiance aux résultats qu’elles n’ont pas produits elles-mêmes. Du coup, l’ingénieur devient, selon les mots de Fabien Potencier, une « liste de contrôle humaine » : pas un décideur ni un architecte, mais quelqu’un qui se contente de cocher des cases les unes après les autres pendant que l’agent fait le vrai boulot.

La fatigue devient inévitable. « La fatigue vient du fait de devoir valider chaque étape de toutes les conversations avec les agents », explique-t-il. Il affirme que ce modèle n’est pas viable et ne donne pas de meilleurs résultats ; il ne fait qu’épuiser les ingénieurs.

« Au lieu d’essayer d’avancer le plus vite possible dès le premier jour, on devrait d’abord ralentir, comprendre comment fonctionnent les agents et comment les améliorer ; tout est une question de gestion du contexte. Ça prend du temps ; ce n’est pas encore une science, donc il faut investir du temps pour apprendre à le faire », explique Fabien Potencier.

L’effet cumulatif

À mesure que la confiance s’accumule, les connaissances s’accumulent aussi. « Chaque exécution améliore la suivante », dit-il, « parce qu’on partage nos compétences et nos invites. » Lorsque les agents tournent sur une infrastructure partagée plutôt que sur des machines individuelles, les compétences affinées après chaque exécution, les consignes améliorées à chaque rétrospective et le contexte accumulé au fil du temps appartiennent à toute l’équipe, pas seulement à la personne qui a exécuté le processus.

Les processus s’améliorent, le contexte s’enrichit, et l’agent devient plus apte à comprendre non seulement la tâche, mais aussi les normes et les conventions de l’équipe spécifique avec laquelle il travaille.

C’est cet effet cumulatif qui distingue les équipes qui tirent pleinement parti des agents de celles qui restent bloquées en mode supervisé. Le résultat, ce n’est pas seulement du code, mais un système qui comprend leur base de code et sur lequel on peut compter pour appliquer leurs normes de manière cohérente.

Ce que ça signifie pour les responsables techniques

Le « cadran de confiance » n’est pas une fonctionnalité du produit ; c’est une façon d’envisager la relation entre le jugement humain et les systèmes automatisés, une relation que chaque équipe d’ingénierie devra développer de manière délibérée ou découvrir par hasard, en réagissant aux événements.

Construire la confiance petit à petit, codifier ce qui marche et gagner en autonomie grâce à des preuves plutôt qu’à des suppositions, c’est la condition préalable à tout ce qui va suivre : sortir les agents des machines individuelles, faire tourner des processus dans toute l’équipe et, à terme, faire fonctionner ce genre d’usine logicielle autonome où l’agent fait son boulot et où les humains se concentrent sur ce qu’eux seuls peuvent faire.