Utiliser vs Piloter
La confusion est massive. Quand une organisation dit "on utilise l'IA", elle décrit dans 90 % des cas la même chose : quelqu'un ouvre une fenêtre de chat, tape une demande en langage naturel, et accepte ce qui arrive.
C'est de l'utilisation. C'est utile. Ce n'est pas du pilotage.
La distinction n'est pas une question de prompts plus longs ou de techniques avancées. Elle est dans la posture : est-ce que le pilote évalue le livrable contre des critères objectifs, ou est-ce qu'il l'accepte parce qu'il "semble correct" ?
Le piège de la plausibilité
L'IA produit toujours quelque chose de lisible. Structuré. Professionnel en apparence. C'est précisément ce qui rend le pilotage indispensable : la défaillance n'est jamais évidente. Un livrable peut satisfaire la demande en surface tout en manquant l'intention — et sans critères d'acceptance définis en amont, cette différence est indétectable.
| Dimension | Utilisation | Pilotage |
|---|---|---|
| Critères d'acceptance | Évalués après réception | Définis avant production |
| Refus d'un livrable | Rare — "c'est bien" | Systématique si critère non rempli |
| Itération | Relance depuis zéro | Repart du delta documenté |
| Rôle assigné à l'IA | Implicite | Explicite, adapté au livrable |
| Traçabilité | Aucune | Chaque décision documentée |
Le Méta-Prompting
Le principe : on fournit tout le contexte (fichiers, données, documents de référence) et on demande à l'IA de construire le protocole d'analyse idéal pour ce contexte précis. On valide ou amende ce protocole. Elle travaille ensuite dans le cadre qu'elle a elle-même formalisé sous contrainte.
Pourquoi ça change tout
En forçant l'IA à formaliser son protocole avant d'exécuter, on élimine la principale source de drift : l'IA qui remplit les zones d'ambiguïté avec des hypothèses statistiquement probables plutôt qu'avec ce qui est contextellement exact.
Résultat : l'IA produit un protocole structuré que le pilote valide ou amende. Elle exécute ensuite dans ce cadre — pas dans ses approximations par défaut.
Les trois niveaux de cadrage
| Niveau | Ce qu'on donne | Ce qu'on obtient |
|---|---|---|
| Utilisation | Une question en langage naturel | Réponse statistiquement probable |
| Prompt structuré | Contexte + rôle + contraintes | Réponse cadrée, plus pertinente |
| Méta-Prompting | Matériau source + instruction méta | Protocole validé → exécution dans le cadre exact |
Ce n'est pas de la magie. C'est de l'ingénierie de la contrainte appliquée en amont.
La Boucle de Refus
Un backlog IA fonctionne comme un backlog Scrum : liste ordonnée de livrables, dépendances identifiées, critères d'acceptance écrits avant production. Sans cette étape, la recette est subjective et le livrable contestable.
Structure d'une user story pour l'IA
Le format "En tant que / Je veux / Afin de" reste valide. Ce qui change, c'est la précision chirurgicale des critères d'acceptance — chacun doit être vérifiable objectivement, pas au ressenti.
User story : En tant que visiteur dirigeant de PME, je veux comprendre en moins de 10 secondes ce que propose ce service et à qui il s'adresse, afin de décider si ça me concerne.
Critères :
— Le titre ne contient pas le mot "rédaction" — trop générique
— La cible (dirigeant PME) est explicite dans les 8 premiers mots
— Aucune liste à puces dans le hero — une seule promesse, pas un catalogue
— Le CTA décrit ce qui se passe après le clic — pas "En savoir plus"
— Moins de 40 mots visibles au-dessus de la ligne de flottaison sur desktop
Le protocole en trois temps
- 01Identifier le critère non satisfait. Pas "c'est pas top" — "le critère 3 n'est pas rempli : il y a une liste à puces dans le hero".
- 02Refuser — ne pas corriger à la main. Modifier soi-même la production IA contourne la boucle de rétroaction. Le prochain livrable héritera des mêmes défauts structurels.
- 03Reformuler en contrainte plus serrée et relancer. La contrainte est plus restrictive qu'initialement — pas une reformulation du même brief.
Refus amateur vs refus opérationnel
"Ce n'est pas vraiment ce que je voulais. Tu peux essayer d'une autre façon ?"
Aucune contrainte nouvelle. L'IA produit une variation du même output défaillant.
"Livrable refusé. Critère 3 non satisfait : liste à puces dans le hero. Contrainte ajoutée : format prose uniquement, une seule phrase d'accroche, zéro énumération."
L'IA modifie son approche, pas juste sa formulation.
La Boucle de Refus en conditions réelles
Avant mise en ligne d'un site PHP, chaque livrable technique a été soumis à un audit de sécurité avec cette discipline. Les refus couvrent deux niveaux de criticité différenciés : failles critiques exploitables immédiatement, et défauts de conformité sans impact direct mais réels.
7 livrables refusés, 7 corrections imposées avant déploiement. Score sécurité A+ en résultat.
Lire l'audit complet → 7 refus documentés
L'Orfèvrerie par l'Itération
La méthode transforme une idée floue en livrable précis en cinq strates. Chaque strate réduit le champ des possibles. À la sortie, il ne reste que ce qui est exact, défendable, et cohérent avec les livrables précédents.
Les cinq strates de l'entonnoir
- S1Injection du contexte. On fournit tout le matériau source. Aucune interprétation à ce stade — l'IA reçoit les faits bruts.
- S2Construction du protocole (Méta-Prompting). On demande à l'IA de construire son propre protocole d'analyse. On valide avant toute production.
- S3Premier livrable dans le cadre. L'IA produit dans le cadre du protocole validé. Objectif : identifier les défaillances contre les critères d'acceptance.
- S4Itérations contraintes (Boucle de Refus). Chaque défaillance devient une contrainte supplémentaire. Les itérations sont bornées — une défaillance à la fois.
- S5Validation et clôture. Chaque critère est coché explicitement. Le livrable est documenté et classé. On ne revient pas dessus.
La règle d'or des itérations
Prompt 1 : demande vague. Prompt 2 : "peux-tu le rendre plus percutant ?" Prompt 3 : "essaye encore".
Itérations non bornées, drift croissant, résultat non défendable.
Prompt 1 : brief complet + critères. Défaillance identifiée. Prompt 2 : même brief + contrainte ajoutée précisément.
Chaque itération tracée, contrainte documentée, convergence garantie.
Les décisions que l'IA ne peut pas prendre
L'IA peut exécuter dans n'importe quel cadre qu'on lui impose. Ce qu'elle ne peut pas faire : définir ce cadre elle-même. Et en particulier, elle ne peut pas prendre ces décisions à la place du pilote :
- Le niveau d'exigence — ce qui est "fini" vs "passable". L'IA acceptera toujours ce qui est passable si on ne lui impose pas la barre du fini.
- Le positionnement — à qui, contre qui, avec quelle promesse. Arbitrages stratégiques qui engagent une connaissance du marché que l'IA n'a pas.
- Les priorités — ce qui est bloquant vs ce qui peut attendre. La priorisation intègre des contraintes de délai, de dépendances, de budget que l'IA ne connaît pas.
- Le prix — l'IA fournit des benchmarks. Elle ne connaît pas la marge cible, le positionnement voulu, la perception de valeur dans le contexte précis.
- Le ton juste — l'IA produit toujours quelque chose de "professionnel". Ce n'est pas toujours ce qu'on cherche.
- La cohérence transversale — l'IA travaille livrable par livrable. La vision d'ensemble n'apparaît qu'au niveau du pilote.
Le Zéro Défaut comme standard d'exigence
Dans un système où une défaillance a des conséquences réelles, on ne livre pas ce qui "devrait marcher" — on prouve que ça marche. Appliqué à l'IA : c'est le pilote qui fixe la barre du "fini". L'IA ne sait pas ce que "suffisamment bon" veut dire pour ce contexte précis.
Le ROI de la méthode
Le coût d'un mauvais pilotage IA n'est pas le coût de l'outil. C'est le coût du temps perdu à corriger ce qui a été mal spécifié, à reconstruire ce qui a divergé sans boucle de rétroaction, à reprendre ce qu'on aurait dû refuser au premier livrable.
Le cycle de la mauvaise spécification
- 01L'IA produit quelque chose de lisible. Le rejet de la plausibilité n'est pas activé. On continue.
- 02Sans boucle de rétroaction active, l'imprécision se propage. Chaque livrable hérite des défauts du précédent.
- 03Le problème remonte. Retour en arrière sur 3 à 5 livrables en cascade pour trouver l'origine.
- 04Refaire le livrable source, reconstruire les dépendants, re-valider l'ensemble — sans les critères d'acceptance qui auraient évité le problème.
Comparaison des deux approches
Itérations non bornées. Livrables validés au ressenti. Dette technique accumulée.
Produit approximatif, incohérences structurelles, corrections en production.
Chaque livrable évalué contre des critères objectifs. Incohérences détectées à la recette unitaire.
Produit cohérent, sécurisé, livré dans les délais.
Exemple de compression R&D
Architecture sur mesure · sécurité A+ certifiée · RGPD natif · SEO Schema.org. Équivalent classique : 4 à 6 mois, 25 000€ à 40 000€.