Un terme technique devient parfois viral pour une bonne raison : il nomme quelque chose que tout le monde observait déjà sans avoir les mots pour le dire. C’est le cas du « loop engineering », popularisé récemment par Boris Cherny, créateur de Claude Code, et Peter Steinberger, créateur d’OpenClaw.
L’idée mérite qu’on s’y arrête, pas parce que le vocabulaire est nouveau, mais parce qu’il révèle un changement réel dans la façon dont le code se produit aujourd’hui — et dans la façon dont les décideurs non techniques devraient penser leurs projets numériques.
Les trois boucles
Cherny décrit trois boucles distinctes qui structurent le travail avec un agent IA de développement, chacune avec son propre rythme.
La première est la boucle d’ingénierie agentique. On donne à l’agent une spécification et parfois un jeu de tests (des « evals », des critères mesurables de réussite). L’agent écrit du code, le teste lui-même, corrige, recommence. Cette boucle tourne vite — quelques minutes entre deux itérations — et fonctionne sans supervision humaine constante. Cherny raconte avoir laissé un agent travailler seul pendant près d’une heure sur une application, l’agent vérifiant son propre travail dans un navigateur avant de revenir vers lui.
La deuxième est la boucle de rétroaction du développeur. Ici, une personne observe le résultat produit et réoriente l’agent : ajuster le design, changer une fonctionnalité, revoir un parcours utilisateur. Cette boucle est plus lente, elle se mesure en dizaines de minutes ou en heures, parce qu’elle demande un jugement humain sur le produit.
La troisième boucle, plus large encore, concerne les décisions de ce qu’il faut construire en premier lieu — la stratégie produit elle-même.
Pourquoi c’est important
Ce découpage en boucles change une hypothèse répandue : que l’IA remplace le développeur. Ce n’est pas ce que décrit Cherny. L’agent prend en charge une tâche précise — écrire, tester, corriger — mais quelqu’un doit continuer à décider ce qui vaut la peine d’être construit et ce qui fonctionne réellement pour l’utilisateur final.
Autrement dit, le travail ne disparaît pas. Il se déplace. Une bonne partie du temps que les développeurs passaient à chercher des bugs manuellement revient maintenant à l’agent, qui teste son propre code de façon systématique. Le temps humain libéré se réinvestit dans des décisions à plus forte valeur : quelles fonctionnalités prioriser, où l’interface doit s’améliorer, comment le produit doit évoluer.
Pour une agence ou une PME qui commande du développement, la question change. Ce n’est plus « combien de temps ça va prendre », mais « à quelle boucle appartient cette tâche, et qui doit la superviser ».
Ce que cela change pour les entreprises
Concrètement, trois choses évoluent dans la façon de commander et de piloter un projet numérique.
D’abord, la spécification devient l’élément le plus précieux du projet. Un agent qui itère seul pendant une heure ne produit un bon résultat que si le point de départ — la spécification — était clair. Le temps qu’on gagnait autrefois à écrire du code à la main se réinvestit maintenant dans le fait de bien décrire ce qu’on veut construire.
Ensuite, le rôle du développeur senior se déplace vers la supervision et la décision, plutôt que vers la production ligne par ligne. Une organisation qui évalue ses prestataires uniquement sur le nombre d’heures facturées risque de mal mesurer la valeur produite : l’agent absorbe une partie du travail répétitif, mais le jugement humain sur les priorités reste entier.
Enfin, ces boucles compriment l’échelle de temps d’un projet. Des ajustements qui prenaient des jours peuvent maintenant se faire en heures. Cela ouvre la porte à des cycles de validation plus courts avec le client, à condition que les processus internes suivent ce rythme.
Les opportunités
Pour les organisations qui commandent du développement, plusieurs pistes concrètes se dégagent.
Les projets à spécification claire — un formulaire, une migration, un tableau de bord bien défini — deviennent plus rapides et moins coûteux à produire. C’est le terrain où la boucle d’ingénierie agentique excelle.
Le temps du développeur senior, libéré de la production répétitive, peut se réorienter vers la conception : structurer l’architecture, définir les priorités produit, anticiper les cas limites qu’un agent ne détecte pas seul.
Pour une agence comme FD Stratégies, cela ouvre aussi une piste de positionnement : facturer la qualité de la spécification et du jugement stratégique plutôt que le volume d’heures de code écrit.
Les risques et angles morts
La démarche a aussi ses angles morts. Un agent qui teste son propre code contre ses propres critères peut passer à côté d’un problème que ces critères ne couvrent pas — un biais de confirmation appliqué au logiciel. La qualité des evals détermine la qualité du résultat, et construire de bons evals demande une expertise qui ne s’improvise pas.
La boucle de rétroaction du développeur reste indispensable, et c’est justement celle qu’une organisation pressée est tentée de raccourcir. Réduire cette étape pour aller plus vite revient à sauter le moment où on vérifie que le produit sert réellement l’utilisateur, pas seulement la spécification écrite.
Il faut aussi rester prudent avec le vocabulaire. « Loop engineering » décrit une pratique observée chez des praticiens avancés, pas une méthode standardisée ou universellement applicable. Une petite équipe sans processus de tests solides ne bénéficiera pas des mêmes gains qu’une équipe outillée pour construire des evals rigoureux.
Mon analyse
Ce qui me frappe le plus, c’est que le loop engineering formalise une intuition que beaucoup d’équipes techniques avaient déjà, sans la nommer aussi clairement. La vraie valeur n’est pas dans le mot « loop engineering » lui-même, mais dans la discipline qu’il implique : séparer clairement ce qui peut tourner en boucle rapide et automatisée de ce qui exige un jugement humain plus lent et plus réfléchi.
Pour une PME ou un OBNL qui envisage un projet numérique, la question à poser à son prestataire n’est plus « utilisez-vous l’IA ». C’est devenu une évidence. La bonne question est : « comment structurez-vous vos boucles de validation, et à quel moment mon jugement de client entre-t-il dans le processus ? » La réponse à cette question distingue un prestataire qui a simplement ajouté un outil IA à son flux de travail d’un autre qui a repensé sa méthode autour de ces boucles.
Conclusion
Le loop engineering n’invente pas une nouvelle catégorie de logiciel. Il décrit avec précision comment les agents IA transforment le rythme et la répartition du travail de développement — plus vite sur l’exécution, toujours humain sur le jugement. Pour une organisation qui commande du développement, la leçon pratique est simple : investissez dans la clarté de vos spécifications, gardez une place ferme pour la validation humaine, et méfiez-vous de tout prestataire qui prétend avoir automatisé cette dernière étape.
Vous souhaitez appliquer ces idées à votre organisation ? FD Stratégies peut vous accompagner dans la création de solutions numériques, l’automatisation de vos processus et la structuration de votre présence en ligne.
