Entrez, la porte de l’Atelier est ouverte.

Posez votre prompt sur l’établi, prenez un café et évitez de toucher au petit tournevis à gauche. Je le cherche depuis trois jours.

Dans les articles précédents — retrouver le fil puis démarrer demain matin — nous avons déroulé le fil de Golden Thread :

Besoin
   ↓
Readiness
   ↓
Délégation à l’agent
   ↓
Validation
   ↓
Capitalisation

Aujourd’hui, nous allons nous arrêter sur cette deuxième étape.

Parce que c’est souvent là que l’on saute trop vite à la construction.

La readiness.

Un mot anglais, parce qu’il fallait bien trouver une manière élégante de dire :

Est-ce qu’on est suffisamment prêt pour confier ce travail à une IA sans transformer la suite en partie de dés truqués ?

On pourrait traduire readiness par « préparation ». Le terme serait correct, mais un peu faible. Préparer une tâche peut se limiter à rassembler quelques documents et rédiger un prompt.

La readiness pose une question plus exigeante :

Avons-nous suffisamment compris le problème pour déléguer une partie de sa résolution ?

Et surtout :

Serons-nous capables de reconnaître un bon résultat lorsqu’il arrivera ?

Le castor formule mal ses besoins

Observation un peu vexante : l’être humain n’est pas particulièrement doué pour exprimer ce qu’il veut.

Il possède une intention, quelques contraintes, des évidences qu’il oublie de partager et parfois une solution déjà choisie. Tout cela arrive mélangé dans la même phrase.

Il nous faudrait un chatbot pour retrouver plus vite les documents internes.

La demande semble assez claire pour commencer à travailler.

Elle contient pourtant plusieurs couches.

Il y a un problème supposé : les documents seraient difficiles à retrouver.

Il y a un objectif : réduire le temps nécessaire pour accéder à l’information.

Il y a déjà une solution : construire un chatbot.

Puis viennent les petits détails restés sous l’établi : quels documents, quels utilisateurs, quels droits d’accès, quelle confidentialité, quelle définition de « plus vite » et quelle tolérance aux réponses fausses.

L’auteur de la demande connaît peut-être certaines réponses sans penser à les écrire. Il peut croire qu’elles vont de soi. Il peut aussi ignorer qu’un arbitrage est nécessaire.

Lorsqu’il relit son texte, son cerveau y remet naturellement tout ce qu’il avait en tête.

Lui voit le barrage entier.

Les autres disposent d’un croquis humide sur un coin de serviette.

L’IA, elle, construit quand même

Une IA générative souffre rarement du syndrome de la page blanche.

Donnez-lui une demande floue, elle produira quelque chose. Une architecture, un plan d’action, une application ou trente-sept fichiers TypeScript avec des noms parfaitement raisonnables.

Le résultat aura souvent l’air terminé.

Les titres seront bien alignés. Le code compilera peut-être. Les diagrammes présenteront de jolies flèches. Une conclusion enthousiaste expliquera pourquoi cette approche répond parfaitement au besoin.

Lorsque des informations manquent, le modèle s’appuie sur le contexte disponible et sur les choix qui lui semblent plausibles.

Il remplit les blancs.

Parfois, il les remplit exactement comme nous l’aurions souhaité.

C’est là que le piège devient intéressant.

Une hypothèse silencieuse qui tombe juste reste une hypothèse silencieuse. Elle est simplement plus difficile à repérer.

La première délégation

Dans les vieux conseils d’atelier, on raconte que lorsqu’un bûcheron a un arbre à abattre, il commence par passer quarante-cinq minutes à aiguiser sa hache.

Il pourrait frapper tout de suite. Le geste serait plus spectaculaire et donnerait rapidement l’impression que le travail avance. Mais une lame mal préparée transforme chaque coup en effort perdu.

Nous utilisons spontanément l’IA pour produire.

Écris cette application. Conçois cette architecture. Prépare ce contrat. Implémente cette fonctionnalité.

Mais la première chose à lui déléguer ne devrait peut-être pas être la construction.

Nous pourrions commencer par lui demander d’examiner le terrain.

Pas pour compléter notre besoin à notre place, ni pour transformer trois phrases vagues en spécification impeccable.

Son premier travail serait de nous tendre un miroir.

Voici ce que vous avez réellement dit.
Voici ce que j’ai dû supposer pour le comprendre.
Voici les passages qui permettent plusieurs interprétations.
Voici les décisions que vous semblez avoir prises sans les nommer.
Voici ce qui manque pour juger le résultat.

Dans cette position, l’IA peut être utile — à condition de lui interdire de « réparer » le flou en silence.

Elle peut relire une demande sans partager toutes les évidences implicites de son auteur. Elle peut comparer plusieurs parties d’un document, repérer des contraintes qui se frottent et demander comment sera vérifiée une promesse.

Avant de lui confier la scie et le marteau, on lui demande de contrôler les mesures.

Le Miroir Pur

Dans Golden Thread, nous avons donné un nom à cette première passe : le Miroir Pur.

Dans sa version opératoire, c’est la skill Spec Readiness — Miroir Pur : une passe d’analyse avant conception, délégation ou implémentation. La fiche readiness de l’Atelier en résume l’idée.

Son principe tient en une phrase :

Elle ne cherche pas d’abord à résoudre la demande. Elle cherche à rendre son état réel visible.

Le Miroir Pur ne remplit pas les blancs en silence.

Lorsqu’une information manque, il l’indique. Lorsqu’il déduit quelque chose, il présente cette déduction comme une inférence. Lorsqu’une interprétation semble probable, il la sépare de ce qui a réellement été écrit.

Il ne cherche pas à rendre le besoin plus élégant.

Il montre où il est solide et où les planches bougent encore.

Pour cela, il commence par trier ce qu’il trouve.

Les faits explicites

Ce sont les éléments réellement présents dans la demande ou dans les sources.

Dans notre exemple :

  • un outil doit aider à retrouver des documents internes ;
  • l’objectif annoncé est de les retrouver plus vite ;
  • une interface conversationnelle est envisagée.

Le dernier point mérite déjà un petit drapeau.

Le chatbot appartient-il au besoin ou à la solution imaginée par son auteur ?

Les hypothèses

Ce sont les éléments nécessaires pour avancer, mais qui ne sont pas établis.

On pourrait supposer que les documents sont numérisés, que leurs contenus sont indexables, que les utilisateurs possèdent des droits différents ou que la recherche actuelle est effectivement trop lente.

Certaines hypothèses sont solides. D’autres reposent surtout sur une intuition ou sur l’enthousiasme du moment.

La readiness ne demande pas de travailler sans hypothèses. Aucun projet ne démarrerait.

Elle demande de les voir.

Les interprétations possibles

« Retrouver un document » peut signifier localiser un fichier précis.

Cela peut aussi vouloir dire obtenir une réponse contenue dans plusieurs documents, identifier la procédure applicable ou retrouver une ancienne décision.

Ces lectures conduisent vers des produits différents : moteur de recherche, assistant documentaire, système de questions-réponses ou outil de gestion des connaissances.

L’IA peut exposer ces chemins.

Le choix reste une décision humaine.

Les inconnues, les tensions et les décisions

Quels corpus sont concernés ? Une réponse doit-elle citer sa source ? Que se passe-t-il lorsque deux documents se contredisent ? Que signifie exactement « plus vite » ?

Une demande peut également porter ses propres tensions.

On réclame une expérience sans friction avec une validation humaine systématique. On veut une réponse exhaustive en moins de deux secondes. On demande à l’agent d’être autonome tout en lui interdisant la moindre décision.

Ces tensions signalent généralement un arbitrage à prendre.

Quel risque acceptons-nous ? Qui peut consulter quoi ? Préférons-nous une réponse incomplète mais sourcée, ou une réponse plus fluide avec davantage d’incertitude ? Quel comportement doit bloquer la mise en production ?

L’IA peut rendre ces décisions visibles et en explorer les conséquences.

Elle ne possède pas le mandat nécessaire pour les prendre discrètement à notre place.

Une demande peut être partiellement prête

La readiness ne devrait pas fonctionner comme un grand feu rouge ou vert posé sur l’ensemble du projet.

Une demande peut être suffisamment claire pour explorer, mais trop fragile pour implémenter.

Elle peut permettre de construire un prototype local sans autoriser l’accès à des données réelles.

Elle peut être prête pour comparer plusieurs architectures, sans donner à l’agent le droit d’en choisir une et de modifier le dépôt.

Nous n’avons donc pas besoin d’attendre une spécification parfaite avant toute interaction avec l’IA.

Nous devons adapter la délégation au niveau réel de préparation.

Lorsque beaucoup d’inconnues subsistent, on délègue l’exploration.

Lorsque les décisions structurantes sont prises, on peut déléguer la conception.

Lorsque les critères d’acceptation, les limites et les preuves attendues sont explicites, l’implémentation peut commencer.

À l’inverse, certaines demandes sont déjà prêtes à construire : périmètre fermé, contraintes nommées, cas d’échec connus, critère de succès mesurable. Dans ce cas, le Miroir Pur sera court — et c’est une bonne nouvelle. La readiness n’impose pas de cérémonie : elle évite seulement de scier avant d’avoir mesuré.

La question utile devient :

Quelle partie de cette tâche est prête à être déléguée, à quel agent et sous quelles contraintes ?

Transformer le flou

Une fois les zones fragiles rendues visibles, l’IA peut nous aider à les travailler.

Elle peut produire des questions de clarification. Encore faut-il éviter les grandes questions molles du genre :

Pouvez-vous préciser votre besoin ?

Une question utile vise une inconnue ou une décision précise :

Les réponses doivent-elles respecter les droits d’accès du demandeur au document source ?

Une réponse sans citation est-elle acceptable ?

Quel indicateur permettra de vérifier que la recherche est devenue plus rapide ?

Lorsque deux sources se contredisent, laquelle fait autorité ?

Les réponses peuvent ensuite devenir des critères d’acceptation ou des tests de spécification.

Étant donné qu’un utilisateur ne possède pas les droits d’accès à un document
Lorsqu’il interroge l’assistant sur son contenu
Alors la réponse ne doit révéler aucune information issue de ce document
Et l’existence même du document ne doit pas être confirmée

Nous ne testons pas encore une fonction particulière ou une base vectorielle.

Nous testons notre compréhension du besoin.

Le scénario agit comme un petit crash-test de la spécification. Lorsqu’il est impossible de décider ce qui devrait se produire, le problème n’est probablement pas encore prêt à devenir du code.

L’IA peut nous aider à résister à l’IA

Il y a quelque chose d’un peu paradoxal dans cette approche.

Nous utilisons un modèle capable de produire une réponse convaincante à partir d’une demande incomplète pour repérer que notre demande est incomplète.

Tout dépend du rôle que nous lui confions.

Lorsqu’on lui demande immédiatement une solution, il cherche une trajectoire plausible vers cette solution.

Lorsqu’on lui demande de distinguer ce qui est dit, supposé, interprété ou encore indécis, nous exploitons sa capacité à examiner plusieurs formulations et à comparer des contraintes.

Son analyse peut elle-même être imparfaite. Le Miroir Pur reste une aide à la réflexion, pas une autorité chargée de certifier la vérité.

Mais il crée un moment précieux avant la production.

Un moment pendant lequel le but n’est pas encore d’aller vite.

Le but est de découvrir dans quelle direction nous sommes réellement en train de partir.

Être prêt à entendre que le barrage fuit

Cette inspection prépare aussi la validation future.

Lorsque les hypothèses sont visibles, nous savons lesquelles devront être vérifiées.

Lorsque les inconnues sont nommées, nous savons lesquelles bloquent encore certaines décisions.

Lorsque les critères d’acceptation existent, nous disposons d’autre chose que notre impression pour évaluer le livrable.

C’est important, parce que l’IA apporte parfois une étrange sensation de puissance.

En quelques heures, on obtient une application, un audit, une architecture ou un plan stratégique qui aurait autrefois demandé plusieurs jours. Le résultat est cohérent, détaillé et suffisamment propre pour être montré.

Il ressemble à une preuve de maîtrise.

Puis quelqu’un du métier passe devant l’établi.

Il pose une question désagréable. Il remarque une hypothèse fragile. Il demande ce qui se passe lorsque le cas nominal cesse de fonctionner.

La réaction à cette critique en dit parfois davantage que le livrable lui-même.

Je vois passer des entrepreneurs qui construisent avec l’IA des choses réellement impressionnantes. Des développeurs, des consultants et des managers se font emporter par le même courant.

Le produit fonctionne. La démonstration convainc. Le document est beau.

La remarque du spécialiste devient difficile à entendre, parce qu’elle semble remettre en cause la maîtrise acquise en produisant le livrable.

Pourtant, mon intuition est celle-ci : la vitesse de production peut augmenter beaucoup plus rapidement que notre capacité à comprendre et à évaluer ce qui vient d’être produit.

La readiness installe un premier garde-fou. Elle nous oblige à décider, avant de tomber amoureux du résultat, ce qui pourrait nous conduire à le refuser.

Une skill à poser sur l’établi

Le Miroir Pur peut être utilisé sur une idée, un ticket, une spécification, un prompt ou une décision d’architecture.

Sa consigne de base tient dans ce petit bloc :

Analyse cette demande avant toute proposition de solution.

Sépare clairement :
- les faits explicites ;
- les inférences ;
- les hypothèses solides ;
- les hypothèses fragiles ;
- les interprétations possibles ;
- les inconnues ;
- les contradictions ou tensions ;
- les décisions requises.

Identifie ensuite :
- les risques de mauvaise interprétation ;
- les éléments que tu ne dois pas inventer ;
- les questions bloquantes ;
- les critères qui permettraient d’évaluer le résultat.

Ne complète aucun blanc silencieusement.
Ne propose pas encore de solution.
Indique quelles parties sont délégables en l’état.

On peut ensuite lui demander de transformer les réponses validées en critères d’acceptation, en scénarios de test ou en spécification prête à être confiée à un agent.

Une première version publique est déjà dans le dépôt Golden Thread : la skill spec-readiness (Miroir Pur). On peut copier SKILL.md dans l’outil de son choix, ou s’appuyer sur la fiche readiness de l’Atelier pour garder le fil conceptuel.

Pas comme une formule magique.

Comme une discipline reproductible pour éviter de confondre fluidité et clarté.

Le premier travail de l’agent

Golden Thread cherche à conserver un fil entre l’intention initiale et ce qui sera finalement livré, validé puis transmis.

La readiness protège le début de ce fil.

Elle ne demande pas à l’humain de rédiger seul le prompt parfait avant d’avoir le droit de parler à l’IA. L’IA peut justement nous aider à mieux voir notre propre demande.

Il faut simplement changer l’ordre des opérations.

Nous ne commençons plus par dire :

Construis-moi ce barrage.

Nous commençons par demander :

Voici ce que je crois vouloir construire. Montre-moi ce qui est certain, ce que je suppose, ce que je n’ai pas décidé et ce qui risque de céder.

Alors seulement, nous pouvons choisir ce qui sera délégué, quelles preuves seront attendues et où l’humain devra rester dans la boucle.

Être prêt à déléguer ne demande pas d’avoir réponse à tout.

Il faut avoir rendu visibles les endroits où les réponses manquent encore.

Et peut-être accepter qu’avant de manier la scie, le premier talent attendu de notre agent soit de pointer la planche sur laquelle nous nous apprêtions à poser le pied.

En résumé

Avant de laisser une IA construire, rendez visibles les faits, les hypothèses, les interprétations, les inconnues et les décisions. Déléguez d’abord l’examen du besoin — le Miroir Pur — puis adaptez le niveau de délégation à ce qui est réellement prêt. La readiness ne demande pas d’avoir réponse à tout : elle demande de voir où les réponses manquent encore.

FAQ

La readiness exige-t-elle une spécification parfaite ?

Non. Elle demande un niveau de préparation adapté à ce que l’on délègue : explorer, concevoir ou implémenter ne demandent pas le même degré de clarté.

Pourquoi l’IA remplit-elle les blancs ?

Parce qu’on lui demande souvent une solution. Face à une demande incomplète, un modèle cherche une trajectoire plausible — et comble ce qui manque sans toujours le signaler.

Que faire des hypothèses ?

Les nommer. La readiness n’interdit pas les hypothèses ; elle refuse qu’elles restent silencieuses.

Par où commencer concrètement ?

S’approprier la skill Spec Readiness — Miroir Pur sur une vraie demande, ou utiliser le prompt ci-dessus si l’on préfère rester léger. La fiche readiness de l’Atelier rappelle le cadre. Ne pas hésiter à la modifier et à la raffiner.