Quand l'usage de l'IA fait (re)découvrir les pratiques tech et produit

J’ai remarqué quelque chose d’assez marrant ces dernières semaines. En tout cas, quelque chose qui me fait sourire.

Je suis pas mal les nouveautés autour de l’IA et des agents. Parfois via le canal créateurs de contenu qui expérimentent beaucoup avec les agents. Ils testent les outils, partagent ce qui fonctionne, leurs use case, et ils inventent parfois de nouveaux mots pour décrire leurs façons de faire.

Et puis je suis tombé sur ce tweet de Peter Steinberger, le créateur d’OpenClaw :

Are we still talking loops or did we shift to graphs yet?

Peu de temps avant, je voyais du loop engineering partout. Maintenant, c’est le graph engineering qui commence à faire son apparition.

J’ai voulu comprendre un peu mieux ce qui se cachait derrière. Et je me suis dit : « Ah oui. On est en train de remettre des noms sur des choses que l’on connaît déjà assez bien. »

Pas exactement les mêmes choses, évidemment. Le contexte est nouveau, les outils aussi. Mais il y a comme un air de famille avec pas mal de pratiques tech et produit qui elles sont déjà ancrés depuis bien longtemps.

Avancer par petites étapes, encore et toujours

Le loop engineering, on pourrait dire que ça consiste à donner un objectif et des critères de réussite à un agent plutôt que de lui expliquer comment faire tout son travail. On lui donne un but à atteindre, pas une liste d’étape version notice IKEA. L’agent essaye, observe le résultat, corrige et recommence.

La première chose qui me vient, ce sont les tests d’acceptances. Forcément, il faut donner de bons critères de succès pour que l’agent sache de lui-même quand c’est est-ce qu’il a bien atteint son objectif.

Ça me fait penser aux boucles de feedback que l’on recherche partout quand on fabrique un produit ou du logiciel. On fait une petite chose, on vérifie si elle répond au besoin, on ajuste. Un test automatisé, une démo, un retour utilisateur, une revue de code, autant de façons d’apprendre avant d’avoir construit un gigantesque truc impossible à déplacer.

Ça me fait penser au quoi versus comment. Un PO ne va pas expliquer aux développeurs comment fabriquer la page de connexion. On explique autrement vers où on veut arriver, les collaborateurs ne sont pas de simples exécutants. On va donner de l'autonomie pour que l’équipe décide comment faire. Tiens, on pourrait penser aux OKR aussi.

Même idée avec le graph engineering. Au lieu de demander à un agent de réaliser une immense tâche dans son coin, on la découpe. On confie des responsabilités plus petites, on explicite ce qui dépend de quoi, on peut vérifier chaque morceau plus facilement.

Ça rappelle forcément le découpage d’un problème, les responsabilités bien séparées, les incréments livrables, les petites pull requests, … Bref, tout ce que l’on essaie de faire quand on veut garder un projet compréhensible et qui peut facilement évoluer.

On dirait que les agents aussi préfèrent qu’on évite de leur donner une mission du type : « Refais-moi toute l’application, et si tu as le temps pense aussi à la stratégie marketing. » Qui aurait pu prédire ? :)

Donner le bon contexte

Autre sujet que je vois revenir en permanence : le contexte.

Pour qu’un agent fasse correctement son travail, il faut lui donner les bonnes informations. Les objectifs, les contraintes, les exemples et contre-exemples, les fichiers utiles, la façon dont le projet est organisé, ce qui est acceptable ou non, des critères de succès, etc. Sinon, il devra deviner. Et quand une IA devine, elle le fait souvent avec une confiance assez impressionnante (les fameuses halucinations).

Là encore, ça me semble plutôt familier, et peut-être vous aussi.

Un nouveau développeur qui arrive dans une équipe, un collègue qui reprend un sujet, une personne à qui l’on délègue une tâche : tout le monde a besoin de contexte. Les décisions passées, le vocabulaire métier, les contraintes implicites, la définition de « c’est terminé ». Plus on explicite, plus on s’aligne, plus on travaillera efficacement ensemble.

Les fichiers d’instructions pour agents, les dossiers de contexte et les exemples de livrables sont peut-être de nouvelles façons de faire, mais le besoin qu’ils adressent est bien plus vieux : permettre à quelqu’un — ou quelque chose — de comprendre avant d’agir.

Rien de très neuf au final

Mon propos n’est pas de critiquer les personnes qui parlent de ces sujets, ou dire qu’elles n’inventent rien. Personne n’a la même histoire, le même… contexte. Je trouvais juste cette observation amusante, et j’avais envie de la partager.

Notre usage de l’IA et des agents nous faire (re)découvrir des partiques tech et produit, déjà existante. Sous une forme légèrement différente. Est-ce que l’IA remplacera nos jobs ? J’en sais rien. Mais on dirait que pour le moment, certaines façons de faire reste utile même si l’outil change. Et ça, c’est intéressant.

La culture tech et produit n’a pas pris un coup de vieux. Et c’est peut-être pour ça qu’elle était (et est toujours) pertinente.