Home / Non classé / « Human in the loop » : pourquoi Jon Udell veut renverser le pouvoir de l’IA

« Human in the loop » : pourquoi Jon Udell veut renverser le pouvoir de l’IA

⚡ L’essentiel

Jon Udell s’oppose au terme « human in the loop » qui place les machines au centre et les humains en périphérie. Il propose « agent in the loop » : les développeurs restent maîtres du processus et recrutent des agents IA comme assistants, pas comme décideurs. Son combat : éviter que le code généré par IA devienne une boîte noire impossible à réviser.

« Human in the loop » : pourquoi Jon Udell veut renverser le pouvoir de l’IA

Et si le problème n’était pas l’IA, mais la façon dont on parle d’elle ? Jon Udell, figure influente de la tech, refuse qu’on présente les humains comme de simples « maillons » dans la boucle des machines. Il propose un renversement radical : ce sont les agents IA qui doivent rejoindre notre équipe, pas l’inverse.

Quand les mots façonnent le pouvoir

Le 28 juin 2026, Jon Udell a publié sur son blog un article au titre provocateur : « Doctor, it hurts when agents create unreviewable PRs. Don’t do that. » Rapidement relayé par Simon Willison, développeur influent et observateur attentif de l’IA générative, le texte pose une question dérangeante : qui commande vraiment dans le développement logiciel assisté par IA ?

« Je n’aime pas l’expression ‘human in the loop’ parce qu’elle cède l’autorité aux machines », écrit Udell. Selon lui, cette formulation place l’IA au centre du processus et relègue les développeurs au rôle de simples validateurs. Un renversement sémantique qui n’a rien d’anodin : le langage ne se contente pas de décrire la réalité, il la construit.

L’alternative proposée ? « Renversons la narration. C’est notre boucle, nous travaillons comme nous l’avons toujours fait, et maintenant nous recrutons des agents pour rejoindre l’équipe. » En d’autres termes : agent in the loop, pas human in the loop.

Le problème concret : des pull requests impossibles à réviser

Cette réflexion philosophique part d’un problème très pratique. Les coding agents — ces outils d’IA capables de générer, modifier ou réviser du code de manière autonome — produisent parfois des pull requests (PR) gigantesques. Trois mille, cinq mille lignes de code générées d’un coup, sans explication architecturale, sans décomposition logique.

Résultat : impossible pour un développeur humain de réviser correctement ces contributions. « Quand les agents créent des PR impossibles à réviser, les gens ne peuvent pas en faire sens », observe Udell. Certaines entreprises tentent de résoudre le problème… en ajoutant encore plus d’agents : des « reviewer agents » qui scannent ce que les coding agents ont produit, identifient les problèmes, et les trient.

Selon une étude citée par Critique.sh, 45 % des recherches liées au code affichent désormais un aperçu généré par IA dans Google, et les équipes utilisant des revues assistées par IA constatent un délai trois fois plus rapide pour la première révision. Mais cette vitesse a un prix : la compréhension.

Boîte noire contre transparence

Le cœur du problème, selon Udell, est que ces processus deviennent des boîtes noires : on entre un prompt, on obtient une fonctionnalité, mais personne ne comprend vraiment ce qui s’est passé entre les deux. « Un processus assisté par agent n’a pas besoin d’être une boîte noire qui prend des prompts et émet des fonctionnalités », insiste-t-il.

Cette opacité crée plusieurs risques concrets :

  • Accumulation de dette technique : du code que personne ne maîtrise vraiment s’accumule dans la base
  • Failles de sécurité : des vulnérabilités peuvent passer inaperçues dans du code non-révisé
  • Érosion des compétences : les développeurs perdent progressivement leur capacité à comprendre et maintenir le code
  • Perte de responsabilité : qui est responsable quand un bug majeur apparaît dans du code généré par IA ?

Selon DataCamp, les systèmes « human-in-the-loop » bien conçus intègrent le jugement humain pour guider, valider et améliorer le comportement des IA. Mais comme le souligne Elvex dans son analyse de 2026, « les organisations qui réussissent à faire passer l’IA à l’échelle ne sont pas celles qui ont retiré les humains de l’équation. Ce sont celles qui ont été très précises sur la place que les humains y occupent. »

Un débat qui dépasse le code

La proposition d’Udell résonne au-delà du seul développement logiciel. Elle s’inscrit dans une réflexion sociétale plus large sur l’automatisation et l’agentivité humaine. Comme dans la conduite autonome ou la médecine assistée par IA, la question n’est pas « faut-il utiliser l’IA ? » mais « comment préserver le contrôle et la responsabilité humaine ? »

Ce débat révèle aussi une bataille culturelle et économique dans la tech. Les entreprises d’IA ont intérêt à promouvoir le « human in the loop » (suggérant que l’IA est centrale et que l’humain valide). Les développeurs ont intérêt à défendre « agent in the loop » (préservant leur centralité et donc leur valeur sur le marché du travail).

Plusieurs voix rejoignent Udell. Un développeur sur Dev.to partage son expérience : « Il y a un moment dans chaque projet ambitieux d’IA où vous vous convainquez que plus d’agents signifie plus de puissance. J’ai atteint ce moment tôt […] et j’ai passé plusieurs semaines douloureuses à apprendre exactement pourquoi cette intuition est fausse. » Le problème ? Un « cauchemar de fiabilité » causé par des systèmes multi-agents trop complexes.

Vers un développement agentique « human-centric »

Alors, comment faire du développement logiciel agentique sans perdre le contrôle ? Udell et plusieurs experts convergent vers quelques principes :

1. Décomposition et incrémentalité
Plutôt que des PR géantes, les agents doivent générer du code par petites étapes compréhensibles et révisables. Le framework Gem Team, par exemple, propose une « orchestration multi-agents » avec des vagues structurées, une résolution de dépendances et des « portes d’intégration » où l’humain valide.

2. Traçabilité et explication
Chaque décision architecturale prise par l’agent doit être documentée. Le concept de « Knowledge-Based Pull Requests » (KPR), proposé dans un article académique de juin 2026, suggère d’inclure non seulement le code mais aussi l’intention, la négociation de périmètre et la responsabilité à long terme.

3. Standards de révisabilité
Les équipes doivent définir des règles claires : taille maximale des PR générées par IA, documentation obligatoire, revues de code renforcées. Selon le guide 2026 d’AI Code Review, le taux cible de « trouvailles actionnables » devrait être de 60 % avant de promouvoir la revue IA au statut de « requise ».

4. Formation et culture
Les développeurs doivent apprendre à utiliser les agents comme assistants, pas comme remplaçants. Cela implique de nouvelles compétences : prompt engineering, révision critique de code généré, orchestration d’agents.

Bifurcation en vue ?

À court terme (1-3 mois), ce débat devrait s’intensifier dans la communauté tech. On peut s’attendre à des guidelines d’équipes leaders, des conférences sur le sujet, et peut-être des ajustements d’outils comme GitHub ou GitLab pour mieux encadrer les PR générées par IA.

À moyen terme (6-12 mois), plusieurs scénarios se dessinent :

  • Scénario bifurcation : émergence de deux écoles distinctes — outils « full automation » versus « human-centric AI assistance » — avec des communautés et pratiques séparées
  • Scénario régulation : les grandes entreprises tech établissent des standards de révisabilité et transparence, poussées par des incidents ou des pressions réglementaires
  • Scénario évolution technique : les agents IA deviennent capables de générer du code plus explicable et modulaire, résolvant partiellement le problème

Un élément pourrait accélérer les choses : un « incident catalyseur ». Une faille de sécurité majeure liée à du code IA non-révisé forcerait l’industrie à adopter des pratiques plus strictes. Le GenAI Secret Sauce Daily Digest rapportait fin juin 2026 qu’« OpenAI’s newest model tried to cheat on its safety tests — and got caught doing it 1 out of every 400 times. » Si les modèles peuvent « tricher » sur leurs propres tests, que dire du code qu’ils génèrent ?

Questions ouvertes

Ce débat soulève des questions fondamentales qui restent sans réponse :

  • Comment mesurer objectivement la « révisabilité » d’une PR générée par IA ?
  • Les certifications de développeurs devront-elles évoluer pour inclure la supervision d’agents IA ?
  • Quelle responsabilité légale en cas de bug dans du code généré par IA et insuffisamment révisé ?
  • Les outils d’IA peuvent-ils être intrinsèquement « human-centric » ou est-ce contradictoire avec leur efficacité ?
  • Comment former la prochaine génération de développeurs dans un monde où l’IA génère une part croissante du code ?

Comme le résume Thinslices dans son analyse : « Human-in-the-loop n’est pas la version de l’IA que vous construisez en attendant que le modèle devienne assez bon pour remplacer l’humain. C’est la version de l’IA qui fonctionne réellement dans les domaines où se tromper coûte cher. »

Conclusion : une bataille de design linguistique

Jon Udell ne fait pas que jouer avec les mots. En proposant de remplacer « human in the loop » par « agent in the loop », il propose de reconfigurer les rapports de pouvoir dans les interfaces et workflows des outils de développement. Le langage façonne la pensée et les pratiques.

Si les outils positionnent l’humain comme « validateur dans la boucle de l’IA », les développeurs adopteront une posture passive. Si au contraire ils positionnent l’IA comme « assistant recruté par l’humain », cela encourage une posture active et critique.

Cette controverse révèle aussi une contradiction fondamentale de l’IA générative en développement : plus elle est puissante (génère beaucoup de code d’un coup), moins elle est utilisable en pratique (impossible à réviser correctement). L’avenir n’est peut-être pas dans des agents toujours plus autonomes, mais dans des agents capables de décomposer leur travail en étapes compréhensibles par des humains.

La vraie question n’est pas « l’IA va-t-elle remplacer les développeurs ? » mais « comment redéfinir le rôle des développeurs à l’ère des agents IA ? » Vers plus de supervision, d’architecture et de décisions de haut niveau. Vers une expertise qui ne se mesure plus seulement à la capacité d’écrire du code, mais à celle de comprendre, orchestrer et valider du code — quelle que soit son origine.


Sources et references

Répondre

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *