Loops, graphs, et qui décide ce que l'IA fait ensuite

Il y a quelque temps, un développeur connu a posté une question d’une ligne qui a fait le tour de mon coin d’internet: est-ce qu’on parle encore de « loops », ou est-ce qu’on parle de « graphs » maintenant? Aucune explication, aucun fil de discussion. Juste la question. Et pas mal de gens intelligents ont passé les semaines suivantes à débattre de ce qu’il voulait dire.

Je suis le monsieur IA dans la plupart de mes cercles, donc en quelques jours, quelqu’un m’a demandé de traduire. « Loops, graphs — c’est un truc dont je dois me soucier? » Et je lui ai donné la réponse honnête, qui est la raison d’être de ce guide et la raison pour laquelle il est construit comme il l’est: je comprends ce que veulent dire les mots, je pense que le changement qui se cache derrière est réel, et je n’ai pas encore construit une de ces choses d’une manière qui fait tourner un vrai processus pour de vrais enjeux. Prenez donc ceci pour ce que c’est: un texte explicatif écrit depuis le bord de quelque chose dans lequel je suis encore en train de m’aventurer, pas un récit de guerre avec une leçon tirée à la fin. Je reviendrai ajouter les cicatrices une fois que je les aurai.

Mais je ne pense pas que vous deviez attendre mes cicatrices pour comprendre la conversation. Parce que vous allez continuer à entendre ces deux mots, et l’idée qui se cache derrière est franchement l’un des modèles mentaux les plus utiles pour réfléchir à ce qu’est vraiment un « agent IA ». Alors laissez-moi faire la traduction.

D’abord, ce que fait un « agent » quand il travaille

Oubliez les deux mots un instant. Imaginez le modèle mental auquel je reviens sans cesse sur ce site: l’IA comme la brillante nouvelle recrue qui ne connaît rien à votre activité. Un savoir universel, une vitesse incroyable, zéro contexte sur vous.

Maintenant, imaginez que vous ne posiez pas juste une question à cette nouvelle recrue. Vous lui confiez un travail. « Réservez-moi un vol pour Zurich, trouvez un hôtel près du lieu de l’événement, et mettez tout ça dans un agenda. » Un vrai travail a des étapes, ces étapes dépendent les unes des autres, et certaines peuvent mal tourner.

Tout le débat « loops contre graphs » tourne autour d’une seule question: qui décide de ce qui se passe à chaque étape? C’est tout. Accrochez-vous à ça et le jargon fond.

Le loop: confier tout le travail et lâcher prise

La façon la plus simple et la plus puissante de confier un travail à une IA, c’est ce qu’on appelle un loop. Voici comment ça marche. L’IA regarde où en sont les choses, décide de la seule prochaine action à faire, la fait, regarde le résultat, et décide de l’action suivante, encore et encore, seule, jusqu’à ce qu’elle décide que le travail est terminé.

Voilà le loop. L’IA est à la fois l’exécutante et la responsable. Elle fixe elle-même sa prochaine étape et décide seule quand s’arrêter.

Si vous avez déjà regardé un agent de codage comme Claude Code dévorer une tâche (lire un fichier, lancer un test, corriger l’erreur révélée par le test, relancer), vous avez regardé un loop. Si vous avez utilisé l’un des modes « agent » de ChatGPT ou de Gemini qui part parcourir le web sur plusieurs étapes pour vous répondre, c’était aussi un loop. C’est l’essentiel de ce que les gens entendent aujourd’hui par « agent ».

Et c’est franchement excellent, parce que c’est comme ça qu’on obtient une vraie autonomie sans devoir écrire chaque étape à la main. Vous décrivez la destination; la nouvelle recrue trouve la route. Quand la tâche est petite et bornée (une poignée d’étapes, rien d’irréversible), un loop est exactement le bon outil, et viser plus lourd, c’est de la sur-ingénierie.

Il y a un piège, cependant, et c’est toute la raison d’être du second mot. Parce que l’IA décide de sa propre prochaine étape et de son propre point d’arrêt, vous lui avez confié le volant en entier. La plupart du temps, ça va très bien. Mais réfléchissez à ce que « en entier » veut dire une fois que ça monte en échelle:

• Ça peut s’égarer. Donnez une instruction vague, et un loop peut partir dans un long détour coûteux que vous n’avez jamais demandé: lire quinze fichiers pour corriger un bug d’une ligne, ou construire discrètement une fonctionnalité que personne n’a réclamée, parce qu’à chaque étape, il a jugé que c’était le prochain geste raisonnable.
• Il ne peut pas facilement s’arrêter pour vérifier avec vous. Un loop a tendance à aller jusqu’au bout ou à échouer. Rien n’y prévoit naturellement un « on s’arrête ici et on attend qu’un humain dise oui ». Vous devez le rajouter après coup, tant bien que mal.
• Quand ça casse, ça casse jusqu’au tout début. Si le travail s’effondre à l’étape douze, un simple loop ne peut généralement pas reprendre à l’étape douze. Vous relancez tout — et vous repayez tout.
• Vous ne pouvez pas facilement voir pourquoi il a fait ce qu’il a fait. C’est un long flux continu. Reconstituer le raisonnement après coup revient à lire une transcription et à espérer.

Rien de tout ça ne compte quand c’est vous qui êtes assis là à regarder, à corriger le tir au fur et à mesure. Ça commence à compter énormément quand la chose tourne sans surveillance, selon un horaire, en train de faire quelque chose que vous ne pouvez pas annuler.

Le graph: découper le travail en stations avec des points de contrôle

Voilà donc pour l’autre mot. Un graph, c’est ce qu’on obtient quand on arrête de confier tout le travail et qu’on définit à la place la forme du travail à l’avance.

Au lieu d’un seul loop ouvert, vous découpez le travail en un ensemble d’étapes définies (appelons-les des stations) et vous tracez vous-même les connexions entre elles. L’étape un alimente l’étape deux. Après l’étape deux, si le résultat ressemble à ceci, on passe à l’étape trois; si ça ressemble à cela, on revient en arrière et on réessaie. Certaines connexions sont des portes: l’IA n’a pas le droit de passer tant qu’une vérification n’est pas validée, qu’une règle n’est pas respectée, ou qu’un humain n’a pas cliqué sur approuver.

La version de tous les jours de ça, c’est n’importe quel lieu de travail avec un vrai processus. Une nouvelle note de frais n’est pas payée parce qu’une nouvelle recrue zélée a décidé qu’elle devait l’être. Elle passe par des stations: quelqu’un la saisit, une règle la vérifie par rapport à la politique interne, tout ce qui dépasse un certain seuil demande la validation d’un ou d’une responsable, et alors seulement l’argent bouge. Personne n’appelle ça un « graph », mais c’est exactement ce que c’est: des étapes définies, des passages de relais définis, et une porte solide devant l’action irréversible.

La différence clé avec le loop, en une ligne: dans un loop, c’est l’IA qui décide de la suite. Dans un graph, c’est vous qui décidez de la suite, et l’IA décide seulement de ce qui se passe à l’intérieur de chaque station. Vous avez repris le volant. Vous laissez toujours la brillante nouvelle recrue être brillante, mais seulement dans la voie que vous lui avez tracée.

Et remarquez que le loop ne disparaît pas. Chaque station peut très bien avoir un petit loop qui tourne à l’intérieur (« continuez à affiner ce brouillon jusqu’à ce qu’il passe la vérification »), où l’IA itère librement. Construire un graph n’est pas le contraire des loops. C’est poser un cadre autour d’eux. Les meilleures configurations de production dont j’ai lu parler sont exactement cet hybride: une structure extérieure solide que vous avez conçue, avec des poches d’autonomie libre et bouclée à l’intérieur des cases, là où cette autonomie est sans danger.

Ce que le cadre vous apporte, c’est l’envers de chaque faiblesse du loop citée plus haut. Vous pouvez verrouiller l’étape dangereuse. Vous pouvez mettre en pause à une station et attendre un humain sans que tout le reste ne s’arrête. Quand ça échoue à la station douze, vous reprenez à la station douze au lieu de tout recommencer. Et parce que le travail est organisé en étapes nommées, vous pouvez vraiment voir où ça a mal tourné.

La phrase qui a tout fait basculer pour moi

Au milieu de tout ce débat, une même formule revenait sans cesse chez des gens qui ne s’étaient jamais parlé, ce qui est en général le signe que c’est vrai: le loop vous donne l’autonomie. Le graph vous donne le contrôle. Vous voulez les deux.

C’est tout le sujet. Les graphs ne sont pas la version adulte et les loops le jouet. Ils se trouvent aux deux extrémités opposées d’un curseur entre « laisser tourner » et « garder les rênes », et tout l’art consiste à savoir où placer le curseur pour un travail donné. Une tâche de recherche ponctuelle? Laissez tourner. L’émission automatique de remboursements à des clients? Gardez les rênes, et posez une porte devant le mot « remboursement ».

La métaphore qui circule pour le bout « loop » du curseur, je n’arrête pas de la piquer. Donner à une IA absolument tous les outils possibles « au cas où elle en aurait besoin », c’est comme envoyer quelqu’un vous faire un sandwich tout en lui remettant un bazooka, on ne sait jamais, en cas de zombies. La plupart du temps, il ne se passe rien de grave. Mais vous avez donné énormément de pouvoir à une travailleuse dont vous ne pouvez pas totalement prédire le prochain geste. Un graph, c’est la façon de garder le bazooka enfermé dans une armoire qui ne s’ouvre qu’une fois que la bonne personne a confirmé qu’il y a, effectivement, des zombies.

Qui doit vraiment y réfléchir

Je veux être direct sur ce point, parce qu’une bonne partie de la discussion en ligne l’esquive discrètement.

Si vous êtes quelqu’un qui envoie des requêtes à ChatGPT ou à Claude (écrire, réfléchir, faire des recherches, une chose à la fois, les yeux sur l’écran), la question loop contre graph vous est presque totalement invisible, et c’est très bien ainsi. Vous êtes le point de contrôle. Vous êtes la porte. Vous lisez chaque résultat avant que quoi que ce soit ne se passe à cause de lui. Vous n’avez pas besoin de comprendre la mécanique en dessous, pas plus que vous n’avez besoin de comprendre la boîte de vitesses de votre voiture pour aller travailler. Si quelqu’un vous fait sentir en retard parce que vous n’avez pas d’avis sur les graphs, il confond la plomberie avec la compétence.

L’enjeu grimpe dès que trois choses s’additionnent: l’IA agit de manière autonome (aucun humain ne surveille chaque étape), répétée (un processus, pas un cas ponctuel), et avec des conséquences irréversibles (l’argent bouge, des e-mails partent, des dossiers changent). C’est cette combinaison qui fait passer le « elle décide de tout, y compris quand s’arrêter » du loop de pratique à réellement dangereux, et c’est là que la structure d’un graph justifie son coût.

Ce qui veut dire que c’est surtout une question organisationnelle, pas individuelle. C’est la même limite que je trace sans cesse entre jouer avec l’IA et construire une vraie capacité d’entreprise. La version intéressante de « loops ou graphs » ne concerne pas vos habitudes de chat personnelles. Elle concerne le fait de savoir si le processus automatisé que votre entreprise s’apprête à brancher sur un vrai flux de travail a une porte humaine devant l’étape qui peut faire du tort à quelqu’un. C’est une question de direction déguisée en question d’ingénierie.

Si vous voulez ressentir ce curseur plutôt que de simplement en lire, la chose la plus proche que j’aie construite, c’est le Simulateur d’entreprise sur ce site, un petit jeu sur la délégation de travail à des collègues IA, où toute la leçon est que confier plus d’autonomie sans construire les points de contrôle qui vont avec, c’est exactement comment du bon travail se transforme discrètement en désastre coûteux. Même idée, enjeux plus bas.

Le contrepoids honnête: les graphs ne sont pas gratuits, et pas toujours meilleurs

Si je m’arrêtais là, vous repartiriez en pensant que les graphs sont simplement le choix le plus malin et que tout le monde devrait en construire. Je ne crois pas ça, et surtout, Anthropic non plus, l’entreprise qui a le plus à gagner à ce que vous construisiez des systèmes IA élaborés.

Leurs propres recommandations publiées sont nettement plus prudentes que la version enthousiaste de ce débat. Ils rapportent avoir vu des équipes passer des mois à construire des architectures multi-agents complexes (qui sont des graphs, structurellement), pour découvrir ensuite qu’un meilleur prompt sur un seul agent simple les menait au même résultat. Et ces systèmes ne sont pas bon marché: dans leur propre compte-rendu de l’outil de recherche multi-agent qu’ils ont construit, celui-ci consommait environ quinze fois plus de tokens qu’un chat ordinaire, et ils ont constaté que l’essentiel de la performance supplémentaire venait directement de cette dépense supplémentaire. Leur règle affichée est: commencer par l’approche la plus simple qui fonctionne, et n’ajouter de la complexité que lorsque les preuves qu’on a sous les yeux l’exigent.

Ça correspond à tout ce que je crois sur ce domaine, et ça vaut la peine de le dire clairement parce qu’internet récompense l’inverse. La structure a un coût. Chaque porte que vous ajoutez, chaque station que vous définissez, chaque passage de relais entre les étapes, c’est plus à construire, plus à maintenir, et plus d’endroits où les coutures peuvent craquer. Un graph dont vous n’aviez pas besoin, c’est juste de la bureaucratie que vous avez construite pour un robot. Le bon réflexe n’est pas « comment je transforme ça en graph? » C’est « est-ce que la version la plus simple possible, un seul agent dans un loop, tombe vraiment court ici, et si oui, à quelle étape précisément? » Ensuite, vous ajoutez de la structure à cette étape-là, pas partout.

Il vaut aussi la peine de garder une bonne dose de scepticisme sur les mots eux-mêmes. Les gens qui ont passé leur carrière dans le développement logiciel et l’ingénierie des données vous diront, à juste titre, que « découper un travail en étapes définies avec des dépendances et des points de contrôle » n’est pas une invention nouvelle. C’est comme ça que des flux de travail sérieux sont construits depuis des décennies, aujourd’hui redécouverts avec un vocabulaire neuf parce qu’il y a une IA à l’intérieur des cases, cette fois. La version sans détour d’un ingénieur: c’est quatre-vingt-quinze pour cent de choses qu’on fait depuis toujours, et cinq pour cent de vraiment nouveau parce que les travailleurs sont désormais imprévisibles d’une manière que les composants logiciels ne l’ont jamais été. Ces cinq pour cent sont réels et comptent. Mais ce sont cinq pour cent, pas une révolution, et quiconque vous le vend comme une révolution vous vend quelque chose.

Ce que je fais vraiment à ce sujet, et ce que je vous dirais de faire

Alors, où est-ce que ça laisse quelqu’un qui n’est pas développeur, qui ne veut pas prendre de retard, mais qui ne veut pas non plus construire une chaîne de montage pour un travail qui ne demande qu’un tournevis?

Pour vous-même: rien ne change. Continuez à utiliser les meilleurs outils possibles, continuez à les traiter comme une conversation plutôt que comme un distributeur automatique, et continuez à être l’humain dans le loop qui lit le résultat avant qu’il ne compte. Vous faites déjà tourner le graph le plus sûr qui soit — il a une seule porte, et cette porte, c’est vous.

Le moment où il faut vraiment recourir à cette réflexion, c’est quand vous, ou votre entreprise, commencez à laisser l’IA agir sans que vous ne surveilliez. Le jour où ça arrive, la question à poser n’est pas « loop ou graph » dans l’abstrait. Elle est plus petite et plus utile: où est l’étape qu’on ne peut pas annuler, et qu’est-ce qui se dresse devant elle? Si la réponse est « rien, l’IA décide toute seule », vous avez trouvé l’endroit où une porte doit être posée. C’est toute la discipline, débarrassée de son vocabulaire.

Et moi? Je fais ce que je dis à tout le monde de faire: apprendre en construisant, pas en regardant. J’ai lu suffisamment pour expliquer honnêtement la forme de tout ça, ce que vous venez d’avoir. La prochaine étape, c’est de vraiment mettre sur des rails un petit processus réel et sans surveillance (quelque chose avec une étape qui compte, et une porte devant), et de découvrir où mon modèle mental bien propre rencontre le désordre d’un vrai système. C’est là que vit la connaissance utile, et ce n’est pas une connaissance qu’on trouve dans un diagramme.

Quand je l’aurai, je reviendrai réécrire la fin de ce guide avec ce qui a vraiment cassé. C’est le pacte que je fais avec tout ce qu’il y a sur ce site: je préfère vous dire honnêtement où se trouve la limite de mon expérience plutôt que de faire semblant que la carte est le territoire. En ce moment, sur les graphs, c’est ici la limite. Je vais la déplacer.

---

Ce guide accompagne deux textes plus pratiques sur la même idée de fond, vue de l’intérieur: créer des sous-agents, qui est l’une des formes courantes que prend un « graph » dans la pratique, et donner à Claude une ligne d’arrivée plutôt qu’un script, qui est une petite version pratique du verrouillage d’un loop sur une vraie vérification. Pour l’angle stratégique sur la raison pour laquelle tout ceci relève de la direction plutôt que de l’informatique, Donner Copilot à tout le monde n’est pas une stratégie IA est le texte sur lequel celui-ci s’appuie discrètement.