La conclusion en 5 secondes
Dans l'automatisation par IA, ce qui compte vraiment, ce n'est pas qu'une première réponse arrive vite. C'est d'avoir moins de reprises avant que le travail soit réellement terminé.
Un système de production d'articles, après quelques jours à environ une semaine de refonte intensive, est passé d'un simple « mécanisme qui demande un texte à l'IA et l'enregistre » à une petite usine autonome, dotée de surveillance, de relances, de contrôle des conflits, de sauvegardes intermédiaires, d'isolation des pannes, de barrières de qualité et de gestion des preuves.
Ce qui a fait la différence dans cette grosse refonte, c'est l'idée d'employer ultra tout au début des grands changements de conception. C'est le mode qui ne se contente pas de faire réfléchir GPT-5.6 Sol plus longtemps, mais qui mène aussi plusieurs tâches en parallèle.
Une exécution est lourde. Mais ensuite, il y a moins de « ça, c'était cassé », « l'exécution en parallèle a provoqué un accident », « on n'a pas de preuve » et « tout à refaire encore une fois ». Au final, le temps total diminue.
En langage d'usine : le temps de cycle est long, mais le taux de reprise est faible, donc le délai total de livraison (lead time) est court.
Avertissement d'abord : Level 6 et Level 7 ne sont pas des niveaux reconnus dans le monde entier
Les Level 6 et Level 7 de cet article ne sont ni des niveaux de jeu vidéo ni une norme ISO. Ce sont des étiquettes que j'ai créées pour ce système, afin d'expliquer simplement le degré de maturité de l'automatisation.
L'idée de départ est proche de l'« informatique autonome » (autonomic computing), un sujet que IBM étudie depuis longtemps. IBM résume les propriétés clés d'un système autonome ainsi : il se configure seul, se répare seul, s'optimise seul et se protège seul.
Dans cet article, j'appelle Level 6 l'étape où le système revient de lui-même à un état correct, et Level 7 l'étape où il cherche en plus, de sa propre initiative, de meilleures façons de fonctionner dans une zone sûre.
Au début, il s'agissait juste de « faire écrire des articles par l'IA ». Sans m'en apercevoir, le blog s'est mis à pousser des clôtures
L'automatisation d'articles classique est simple :
- Elle se lance à heure fixe.
- L'IA produit le texte.
- On l'enregistre dans un fichier.
- On le dépose sur GitHub.
- En cas d'échec, un humain regarde.
Cela suffit déjà à rendre bien service.
Mais quand le nombre d'articles grandit, qu'on passe à 12 langues et qu'on automatise aussi l'audit de qualité, les liens internes, les mises à jour et la décision de publier, le problème change.
La vraie question n'est plus « sait-elle écrire ? », mais des questions comme celles-ci :
- Que faire si deux workers (programmes qui exécutent des tâches) touchent le même article en même temps ?
- Si le processus plante en route, à partir d'où reprend-on ?
- Comment éviter de relancer éternellement un travail en échec ?
- Ne réutilise-t-on pas un ancien résultat de contrôle comme s'il était neuf ?
- L'IA n'affirme-t-elle pas de son propre chef qu'« un humain a vérifié » ?
- Qui bloque une publication dans un état où elle ne doit pas sortir ?
- Comment éviter d'arrêter toute l'usine quand un service externe tombe ?
- Le score affiche « 100 », mais ce 100 mesure-t-il vraiment l'état actuel ?
À ce stade, ce n'est plus de l'« automatisation de blog ».
C'est un petit système de production dont la matière première est le contenu.
Level 6 : même cassé, il revient seul à l'état correct
En une phrase, le Level 6 de cette usine est un mécanisme qui revient de façon autonome à une réponse correcte fixée.
Les éléments principaux sont les suivants.
| Mécanisme | Expliqué à un collégien |
|---|---|
| desired state | On définit la « bonne réponse » sous une forme lisible par une machine |
| reconciliation | On compare l'état actuel à la bonne réponse et on corrige s'il y a un écart |
| lease / fencing | Empêche deux personnes de faire le même travail en même temps chacune de son côté |
| checkpoint | Enregistre officiellement jusqu'où le travail est arrivé |
| CAS | N'écrase pas un état récent avec un état périmé |
| transactional outbox | Rattrape le décalage où l'action principale réussit alors que seule la notification échoue |
| retry / quarantine | Relance les échecs passagers et met en quarantaine les données « empoisonnées » |
| safe publication gate | Interdit la publication tant que les conditions de qualité ne sont pas remplies |
| failure injection | Casse volontairement pour tester si la reprise fonctionne vraiment |
| observability | Permet de mesurer ce qui tourne et ce qui échoue |
Dans un instantané d'exploitation, les 21 exigences de conception du Level 6 étaient toutes en PASS et le score de mise en œuvre du contrôle était de 100. En revanche, le score de garantie, qui inclut la mesure externe, la confirmation humaine et le suivi à long terme de tous les workers, était d'environ 69 % ; la publication restait en HOLD et le Level 7 en OFF.
Voilà le point important.
Un 100 sur la mise en œuvre et un 100 qui permet vraiment de laisser tourner l'esprit tranquille, ce n'est pas la même chose.
Même si tous les tests passent, la preuve que le système a réellement fonctionné pendant une semaine, un mois, six mois ne se fabrique pas sans y consacrer du temps.
Le raisonnement profond de Sol et Ultra : « une personne qui réfléchit longtemps » contre « plusieurs personnes en parallèle »
D'après la description officielle d'OpenAI, GPT-5.6 Sol dispose de max, qui le fait raisonner en profondeur, et ultra est un réglage haute capacité qui fait collaborer plusieurs agents sur des lignes de travail parallèles.
Une comparaison.
Quand on fait réfléchir Sol en profondeur
On enferme un excellent concepteur dans une salle de réunion.
« Prends ton temps. Lis tout le code et tous les documents. Trouve les contradictions. Va jusqu'au bout de ta réflexion. »
C'est très puissant.
Dans le cas d'Ultra
Le concepteur, celui qui développe, celui qui traque les bogues, celui qui casse tout et celui qui teste travaillent en même temps, puis les résultats sont réunis à la fin.
Bref, ce n'est pas tant que l'intelligence double que les angles morts se répartissent dans des directions différentes.
D'après les chiffres publiés par OpenAI, sur Terminal-Bench 2.1, GPT-5.6 Sol obtient 88,8 % et Sol Ultra 91,9 %. L'écart est de 3,1 points, mais côté échecs, on passe de 11,2 % à 8,1 %, soit, par un calcul simple, environ 28 % d'échecs en moins. Bien sûr, c'est une seule évaluation, et cela ne veut pas dire que les échecs baissent de 28 % dans tous les types de travaux.
Pourtant, pour un travail divisible comme « lire un dépôt de code gigantesque, concevoir, implémenter, casser et revérifier », le sens de cet écart se comprend facilement.
Pourquoi le lourd Ultra finit-il par être plus rapide ?
Le temps jusqu'à l'achèvement peut se représenter à peu près ainsi :
lead time total = première implémentation + reprises + nouveaux tests + gestion d'incidents + correction des malentendus
Beaucoup de gens ne regardent que le premier terme, la « première implémentation ».
C'est pourquoi l'IA qui répond en 30 minutes paraît rapide et celle qui met 2 heures paraît lente.
Mais si la version de 2 heures supprime 6 heures de reprises qui seraient apparues plus tard, c'est elle la plus rapide.
C'est pareil dans l'industrie.
Une usine qui produit vite et rejette énormément de pièces au contrôle finit par perdre face à une usine qui améliore la capacité de son processus dès le départ et ne fabrique pas de défauts.
Ce qui était intéressant dans ce « coup d'Ultra unique », c'est que la plupart des problèmes découverts ensuite n'étaient pas de ceux qui obligent à refaire la conception de fond.
Ce qu'on a resserré dans les étapes suivantes, c'était par exemple :
- Je veux voir sur une seule page la preuve que tous les workers ont réellement traité des données réelles.
- N'utilisez pas un vieux 50/50 comme le 50/50 d'un nouvel audit.
- N'écrivez pas « relecture humaine » pour une relecture faite par une IA.
- S'il n'y a pas de mesure externe, écrivez « inconnu ».
- Même si un worker n'a rien fait, s'il s'agit d'un NOOP légitime (rien à faire, il est resté inactif volontairement), ne le comptez pas comme un échec.
Ce n'est pas « les piliers étaient à l'envers, donc on reconstruit la maison ».
C'est plutôt le service de contrôle qualité qui entre dans une usine terminée et se montre tatillon jusque sur les étiquettes des tuyaux et l'étalonnage des instruments de mesure.
Pourquoi le « Ultra en une seule poêle » a fonctionné
Je ne dis pas que tout était parfait du premier coup.
Plus exactement, la philosophie de conception initiale était plutôt juste, donc les corrections ultérieures sont restées locales.
Ce qui a beaucoup compté, c'est d'avoir pu intégrer ces questions à la conception dès le début :
- Et si deux exécutions ont lieu en même temps ?
- Et si le processus meurt en cours de route ?
- Et si on traite deux fois ?
- Et si on écrit en tenant un état périmé ?
- Et si seule l'API externe tombe ?
- Et si une donnée en échec boucle indéfiniment ?
- Et si la vérification elle-même est cassée ?
- Et s'il existe une échappatoire permettant de mentir en disant « tout a réussi » ?
D'habitude, on apprend cela une par une, à coups d'incidents en production.
Cette fois, j'ai provoqué à l'avance des accidents du travail virtuels.
Faire tomber le serveur dans les tests avant qu'il tombe pour de bon. Faire pleurer la CI avant qu'un humain ne pleure.
Cet état d'esprit s'accorde aussi très bien avec l'ingénierie du chaos. On y définit l'état normal sous une forme mesurable, on injecte volontairement des pannes qui arrivent dans la réalité, puis on vérifie si cet état normal s'effondre.
Au regard du monde extérieur, qu'est-ce que ça vaut ?
Ici, mieux vaut ne pas en rajouter.
Dire « c'est le système le plus puissant du monde » serait exagéré.
Mais ce n'est pas non plus simplement « j'écris un blog avec l'IA ».
Pour le situer, on peut le voir ainsi :
| Point de comparaison | Distance |
|---|---|
| Faire écrire un article par l'IA et l'enregistrer | Nettement en avance |
| Automatisation en série de type Zapier / n8n | Au moins un cran devant en reprise sur panne et en contrôle des conflits |
| Le back-end sérieux d'un SaaS personnel | Pas mal d'éléments de conception du même niveau |
| Plateforme d'automatisation interne d'une PME | Une comparaison tout à fait valable |
| Un service commercial mature avec des SRE (ingénieurs de fiabilité) dédiés | Encore en dessous en historique d'exploitation, surveillance externe et garanties de sécurité |
| Une infrastructure géante du niveau de Google ou d'Amazon | Une échelle d'un autre univers |
Ce qui est étrange pour un projet personnel, c'est que le code qui a poussé pour savoir comment se comporter en cas d'échec dépasse celui de la fonction d'écriture d'articles.
Quand lease, fencing, CAS, outbox, quarantine et failure injection s'installent dans une usine à articles, ce n'est plus un blog, c'est un centre logistique.
Level 7 : le directeur d'usine se met à tester seul des idées d'amélioration
Au Level 6, la « bonne réponse » est fixée par les humains.
En cas de panne, on revient à cette réponse.
Au Level 7, dans le cadre de la bonne réponse, le système cherche de lui-même de meilleures façons de fonctionner.
Voici l'idée :
- Mesurer en même temps la qualité, la vitesse, le coût, le temps d'attente et le taux d'échec.
- Rendre les conditions de sécurité absolument impossibles à modifier.
- Essayer de nouveaux prompts et ordres de traitement en shadow (un essai en parallèle sans effet sur la production).
- Si cela semble bon, élargir en canary (déploiement progressif) : 5 %, 20 %, 100 %.
- Si la qualité baisse, revenir automatiquement en arrière.
- Quand la fiabilité est mauvaise, ne stopper que les expériences et continuer la production normale.
- Consigner dans un registre d'expériences ce qui a été essayé, ce qui a bien marché et pourquoi on l'a adopté.
C'est proche d'une combinaison de la self-optimization de l'informatique autonome d'IBM, de l'error budget de Google SRE (la quantité d'erreurs qu'on peut tolérer avant de devoir freiner) et du canary et du rollback d'AWS.
Cela dit, il n'y a pas besoin d'installer le Level 7 en production tout de suite.
La raison est simple : je suis encore en train de collecter l'historique à long terme du Level 6.
Si l'on vérifie encore que l'équipement est stable et que l'on dit au directeur d'usine IA « à partir d'aujourd'hui, tu peux aussi changer la vitesse de la ligne tout seul », isoler la cause d'un problème devient pénible.
Si je fais quelque chose maintenant, ce n'est pas le Level 7 lui-même, c'est un renforcement de l'observation, en rassemblant sur une seule page l'activité réelle de tous les workers.
Le mois où l'on paie : en faire un « mois d'investissement en équipement »
Il n'y a guère besoin d'Ultra pour les petites tâches du quotidien.
Pour de petites corrections, des audits de routine ou un traitement de worker déjà bien défini, le Sol ordinaire ou un raisonnement approfondi suffisent souvent.
Ultra est pertinent pour les travaux où un échec entraîne beaucoup de reprises :
- Refonte de tout le système
- Refactorisation à grande échelle
- Réorganisation de la structure des workers
- Conception de la surveillance et de la reprise
- Révision des frontières de sécurité
- La base shadow du Level 7
- Ajout d'un grand nombre de tests et d'injections de pannes
La façon rationnelle de l'utiliser est donc de faire tourner l'usine au quotidien, d'accumuler les chantiers de grande refonte, puis d'investir en équipement d'un seul coup à une période où l'on peut utiliser le mode supérieur.
Plutôt que de voir la facturation de l'IA comme « un abonnement mensuel pour devenir un peu plus malin chaque jour », voyez-la comme le coût d'un chantier pour reconstruire les fondations d'un seul coup.
Avec ce regard, on n'a plus à comparer la valeur d'un modèle lourd uniquement au prix par réponse.
Le plus grand enseignement de cette semaine environ
Le plus grand enseignement, c'est de ne pas mesurer l'intelligence d'une IA uniquement à son taux de bonnes réponses.
Dans le travail réel, ces cinq points comptent :
- La précision de la conception initiale : évite-t-on de tout casser plus tard ?
- La capacité de réfutation : peut-elle démolir sa propre proposition ?
- Le parallélisme : peut-on séparer conception, implémentation, test et audit ?
- La traçabilité : au lieu de « je crois que ça a tourné », peut-on garder la trace de ce qui a réellement tourné ?
- La capacité de reprise : peut-elle se remettre d'un échec sans appeler un humain ?
Autrement dit, une bonne usine à IA n'est pas une « usine qui n'échoue pas ».
C'est une usine qui part du principe qu'elle échouera, ne s'arrête pas quand elle échoue, ne déclare pas de faux succès et peut se remettre sur pied depuis n'importe quel point.
Conclusion : la vitesse, c'est la rapidité avec laquelle on va jusqu'au bout
Si l'on explique en une semaine environ tout ce chemin parcouru par « l'IA a été d'une rapidité folle », on passe à côté de l'essentiel.
Ce qui a fonctionné, c'est d'avoir investi généreusement en puissance de calcul dans la première conception, puis d'être revenu à un fonctionnement ordinaire et économique.
Ultra n'est pas un bouton magique de bonne réponse. C'est plutôt un dispositif qui supprime les reprises en les payant à l'avance.
Même si chaque traitement est lent, si le temps total jusqu'à l'achèvement est court, c'est rapide.
Et ce dont on a besoin à ce stade, ce n'est pas de se hâter d'installer un Level 7 plus intelligent.
C'est de laisser le Level 6 tranquille un moment et de voir s'il continue vraiment à travailler seul.
Quand l'usine aura l'air de s'ennuyer, on pourra alors confier au directeur d'usine IA le pouvoir d'améliorer les choses.
Pour l'instant, lui donner un bouton pour changer la vitesse de la ligne à sa guise serait bien trop amusant.
Références (7)
- OpenAI, GPT-5.6: https://openai.com/index/gpt-5-6/
- OpenAI, GPT-5.6 (version japonaise) : https://openai.com/ja-JP/index/gpt-5-6/
- IBM Research, Autonomic computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- IBM Research, Utility functions: https://research.ibm.com/publications/achieving-self-management-via-utility-functions
- Google SRE, Error Budget Policy: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS, Amazon ECS canary deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
