En bref
En regardant récemment ma façon d’utiliser l’IA, j’ai remarqué quelque chose d’assez drôle.
Je lui décris rarement toutes les étapes dans le détail.
Mes consignes ressemblent plutôt à : « je veux gagner », « réduis mon travail », « ne t’arrête pas en plein milieu », « vérifie que c’est vraiment terminé ».
Ce n’est pas très fin. C’est même franchement grossier.
Mais dès qu’on essaie de satisfaire sérieusement des objectifs aussi larges, l’IA doit elle-même découper les conditions, définir ce que veut dire « terminé », imaginer les vérifications et ajouter des garde-fous là où elle a déjà échoué.
Le flux de travail a donc peu à peu quitté le modèle « un humain contrôle tout à chaque fois » pour devenir : l’IA produit, l’IA contrôle, on compare avec des preuves externes, et l’humain ne reçoit que les anomalies.
En creusant le sujet, j’ai découvert que cette façon de faire ressemble beaucoup au « Harness Engineering » publié par OpenAI en 2026.
L’humain fixe l’intention et les limites. Les agents exécutent.
Le problème, c’est que ce modèle est extrêmement puissant pour un projet personnel et devient soudain beaucoup plus compliqué dans une entreprise.
Un projet personnel, c’est une dictature sans politique.
Dans l’entreprise, le Parlement ouvre la séance.
Le point de départ tient en deux objectifs : gagner plus et travailler moins
Les objectifs de haut niveau sont étonnamment simples.
Pour un jeu de cartes, je veux gagner.
Pour des articles ou de l’automatisation, je veux réduire mon propre travail.
Ces deux objectifs sont puissants parce qu’ils restent simples même lorsque la technique devient compliquée.
Je peux construire un simulateur, lancer des milliers de parties et ajouter des algorithmes de recherche.
À la fin, il reste une question : « Est-ce que le taux de victoire a augmenté ? »
Je peux automatiser les articles, gérer plusieurs langues, ajouter du contrôle qualité, des files d’attente, des empreintes de hachage et des nouvelles tentatives automatiques.
À la fin, il reste une question : « Est-ce que j’ai moins de travail ? »
La mise en œuvre peut devenir très complexe sans que l’objectif doive devenir complexe lui aussi.
Et comme l’objectif bouge peu, je peux laisser beaucoup de liberté à l’IA sur les moyens.
Je ne spécifie pas chaque étape. Si nécessaire, je laisse l’IA dériver elle-même l’état cible
Un humain n’a pas besoin de redéfinir à partir de zéro tous les critères de fin à chaque fois.
On peut partir d’un objectif aussi large que :
« Amène l’article le plus récent jusqu’à sa publication, correctement et sans intervention humaine. »
À partir de là, l’IA peut dérouler elle-même les questions :
- qu’est-ce qui compte exactement comme « le plus récent »
- qu’est-ce que « correct » veut dire
- la traduction correspond-elle toujours à la version actuelle du texte source
- une tâche de 50 éléments peut-elle être déclarée terminée après un seul succès
- le simple fait d’envoyer les fichiers sur GitHub suffit-il pour parler de publication
- faut-il aussi vérifier le site réellement servi
L’humain conserve surtout l’objectif et les invariants qu’il est interdit de violer. Les critères d’acceptation plus détaillés peuvent être dérivés avec l’IA.
Évidemment, l’IA peut aussi se tromper en définissant ces critères.
D’où l’étape suivante : la vérification.
J’utilise énormément l’IA, mais « l’IA dit qu’elle a fini » n’est pas une preuve
Vu de l’extérieur, on pourrait croire que je délègue tout à l’IA.
Et ce n’est pas complètement faux : je délègue l’exécution et je délègue aussi la vérification.
Dans l’idéal, je ne veux même pas lire les journaux.
Le flux de travail parfait serait :
exécuter → vérifier automatiquement → si tout va bien, faire un compte rendu court → s’il y a un problème, ne remonter que la cause et la proposition de correction.
Le point important est de ne jamais transformer l’auto-déclaration de l’IA en critère de fin.
« C’est terminé » ne suffit pas. Il faut aller chercher des éléments observables de l’extérieur : nombre d’éléments traités, résultats de tests, empreintes de hachage, vrai fichier sur GitHub, vraie URL, HTML réellement servi en production.
Si on demande simplement au même modèle, dans le même contexte, de « vérifier son propre travail », il peut répéter deux fois la même mauvaise interprétation.
Une structure plus robuste sépare donc génération, inspection et preuve externe.
L’humain n’a pas besoin de tout lire.
Mais il ne devrait pas non plus accepter un simple « j’ai vérifié ».
En version très directe :
« Je ne vais pas regarder. Vérifie toi-même. Mais ramène les preuves. »
Chaque point de blocage est un endroit où du travail humain survit encore
Quand le véritable objectif est de réduire le travail, tous les petits gestes manuels qui semblaient autrefois acceptables deviennent agaçants.
Il faut cliquer ici à chaque fois.
Cette exception demande un jugement humain.
En cas d’échec, quelqu’un doit ouvrir les journaux.
Après publication, quelqu’un doit encore vérifier à la main.
La réaction habituelle est : « Bon, cette petite partie restera manuelle. »
Mais si l’objectif est justement de travailler moins, cela signifie que la conception n’est pas terminée.
Si un processus ne fonctionne que parce qu’un humain doit faire un effort à un endroit précis, cet endroit reste une dette de conception.
Avec cette grille de lecture, une erreur n’est plus seulement un incident.
Si une tâche devait traiter 50 éléments mais annonce un succès après un seul, il ne suffit pas de lancer les 49 autres.
La vraie question est : « Pourquoi était-il possible de déclarer un succès après un seul élément ? »
Si une vieille traduction passe pour la version actuelle, il ne suffit pas de corriger cette traduction.
Il faut modifier le système pour qu’une traduction obsolète ne puisse plus être considérée comme valide.
Chaque échec transformé en règle retire un peu de travail humain au futur.
Un responsable qui dit « je ne comprends pas » est encore récupérable. Le vrai danger, c’est une relecture qui réécrit la réalité
En août 2026, un article publié sur Zenn racontait l’histoire d’une équipe dont la productivité avait triplé grâce à l’IA tout en laissant une partie de l’équipe derrière elle.
Une scène résume bien le problème : un responsable dit en substance « Je ne comprends pas encore complètement, mais je pense que ce que vous dites est correct. »
Comme relecture technique, c’est faible.
Mais il existe une situation managériale bien plus dangereuse.
Ne pas comprendre, puis réécrire les faits ou les critères après coup afin de préserver sa position hiérarchique.
Il n’y avait aucun critère avant le travail, puis apparaît après coup un « c’était évident qu’il fallait faire comme ça ».
Si vous demandez conseil, on répond « réfléchis toi-même » ; si vous avancez seul, on répond « ne décide pas tout seul ».
Dans cet environnement, il n’existe plus de jeu permettant de se rapprocher d’une bonne réponse, puisque la bonne réponse elle-même se déplace.
À l’inverse, si quelqu’un peut dire « je ne suis pas capable de relire ça aujourd’hui », le système reste réparable : ajouter des experts, automatiser les contrôles, exiger les raisons et les éléments non vérifiés.
Un manque de compétence peut être compensé.
Un critère qui bouge après les faits détruit le mécanisme d’assurance qualité lui-même.
Je comprends mieux maintenant pourquoi le contrôle qualité transformé en rituel me dérangeait autant
À l’origine, les cercles de contrôle qualité, souvent appelés « QC Circles », réunissent de petits groupes de terrain qui améliorent en continu la qualité et leur manière de travailler.
La Union of Japanese Scientists and Engineers décrit elle aussi le QC Circle comme une activité continue de contrôle et d’amélioration menée par les personnes en première ligne.
Le problème n’est pas le contrôle qualité.
Le problème commence lorsque « améliorer réellement » est remplacé par « terminer la forme qui prouve qu’on a fait du contrôle qualité ».
Choisir un thème.
Faire des graphiques.
Le faire entrer dans une méthode QC Story.
Préparer une présentation.
Être évalué.
Applaudir.
Fin.
Ce n’est plus de l’amélioration continue. C’est un concours de cosplay de l’amélioration continue.
La boucle obtenue avec des agents IA est beaucoup moins glamour.
Ça casse.
On cherche la cause.
On cherche les conditions de reproduction.
On modifie le critère de sortie ou le contrôle.
On relance.
On vérifie que la même panne ne peut plus se faire passer pour un « succès ».
Pas de jolie présentation.
Mais la fois suivante, il y a vraiment moins de travail humain.
Ironiquement, cela ressemble davantage à l’idée originale d’amélioration continue.
Sans vraiment m’en rendre compte, je me suis retrouvé assez près du Harness Engineering d’OpenAI
En février 2026, OpenAI a publié « Harness Engineering », qui décrit une méthode de développement centrée sur les agents et Codex.
Dans cette expérience interne, l’équipe s’est imposé la contrainte de zéro ligne de code écrite manuellement et a estimé que le produit avait été construit en environ un dixième du temps qu’aurait demandé une écriture manuelle.
Mais le plus intéressant n’est pas seulement la vitesse.
Le vrai changement est que le travail humain passe de l’écriture de code à la conception de l’environnement, l’expression de l’intention et la construction de boucles de rétroaction.
OpenAI explique également que les contraintes essentielles — limites, exactitude, reproductibilité — doivent être imposées de façon centrale, tandis que les agents disposent d’une grande autonomie à l’intérieur de ces limites.
C’est très proche de cette façon de travailler.
Pas besoin de microgérer chaque détail du « comment ».
Il faut en revanche être clair sur « ce qui ne doit jamais casser ».
Lorsqu’un échec apparaît, on le transforme en documentation, test, analyse automatique des règles (lint) ou règle d’outil pour le prochain passage.
La motivation initiale peut être aussi sophistiquée que « les détails m’ennuient, je n’ai pas envie de les regarder », mais le résultat devient la construction d’un environnement dans lequel les agents peuvent avancer seuls.
Je n’ai pas commencé par lire la théorie.
J’ai pris le chemin de la flemme et je suis arrivé sur la même montagne.
C’est assez drôle.
Un projet personnel est une dictature sans politique. Dans une entreprise, le Parlement ouvre la séance
Dans un projet personnel, ce modèle est très puissant.
Le propriétaire, c’est moi.
L’utilisateur, c’est moi.
L’évaluateur, c’est moi.
Et c’est encore moi qui décide ce que signifie « réussir ».
Si je veux gagner à un jeu de cartes, je regarde si je gagne davantage.
Si je veux travailler moins, je regarde si les interventions humaines diminuent.
Comme la fonction objectif est presque unique, n’importe quel système compliqué produit par l’IA peut être ramené à deux questions très simples :
Est-ce que ça me fait gagner davantage ?
Est-ce que ça me donne moins de travail ?
Un projet personnel est une dictature sans politique.
Et en plus le dictateur est paresseux, donc la bureaucratie IA automatise tout ce qu’elle peut.
Dans une entreprise, d’autres objectifs apparaissent immédiatement.
« Réduire les heures » rencontre les habitudes du terrain, l’audit, les droits d’approbation, les systèmes existants, la responsabilité, l’évaluation et même la raison d’être d’un service.
En 2025, Harvard Business Review résumait une grande partie des obstacles à l’adoption de l’IA en entreprise par les personnes, les processus et les jeux de pouvoir, et pas seulement par la technologie.
Dans un projet personnel, on définit l’état souhaité puis on laisse l’IA optimiser.
Dans une entreprise, définir l’état souhaité est déjà une négociation.
Et toute politique n’est pas forcément absurde.
Conserver une validation humaine pour des raisons d’audit ou de responsabilité peut être parfaitement rationnel.
La conserver uniquement parce que quelqu’un ne veut pas perdre son pouvoir d’approbation est autre chose.
Pour l’IA, les deux cas se ressemblent : « validation humaine obligatoire ».
Décider si cette contrainte est réellement nécessaire reste un problème de société humaine.
Au fond, l’humain n’a peut-être besoin de garder que deux choses : l’objectif et la réalité
À l’ère de l’IA, il n’est plus évident qu’un humain doive concevoir toutes les étapes, tout mettre en œuvre et tout vérifier lui-même.
Définir l’objectif.
Laisser l’IA dériver l’état cible et les critères.
Laisser l’IA mettre en œuvre.
Laisser l’IA contrôler.
Comparer avec des preuves externes.
Quand ça casse, transformer l’échec en règle pour la fois suivante.
S’il reste du travail humain, faire de ce point la prochaine cible d’amélioration.
Si cette boucle fonctionne de manière stable, le besoin pour l’humain de connaître chaque détail de mise en œuvre diminue fortement.
Mais deux questions restent difficiles à déléguer entièrement :
Qu’est-ce qu’on cherche réellement à accomplir ?
Cet objectif correspond-il à la réalité ?
Peut-être que la répartition des rôles finira de plus en plus par ressembler à ceci :
Humain : décide de l’objectif et regarde la réalité.
IA : remplit tout ce qu’il y a entre les deux.
Dans un projet personnel, c’est très confortable.
Dans une entreprise, le Parlement ouvre la séance.
La politique reste invaincue.
