L'IA comme oracle : pourquoi la culture de la vérification compte davantage que le prompting

L’IA est souvent décrite comme un outil, un assistant, un collègue ou un remplaçant. Ces métaphores ne sont pas entièrement inutiles, mais elles poussent souvent les ingénieurs dans la mauvaise direction. Elles déplacent l’attention vers la délégation, la vitesse de réponse et l’impression de productivité, au lieu de la vérification des résultats.

Un modèle mental plus utile pour l’ingénierie est celui de l’oracle.

Le but de cette analogie n’est pas le mysticisme. C’est la discipline opérationnelle.

Ce qu’est un oracle

En informatique théorique, un oracle est une boîte noire hypothétique capable de répondre à une classe définie de questions sans révéler comment elle obtient sa réponse.

En cryptographie, le mot est utilisé plus concrètement pour des services de type oracle, comme des oracles de chiffrement ou de déchiffrement. Un appelant peut soumettre une entrée et observer la sortie, tandis que le mécanisme interne reste caché.

Un LLM n’est pas littéralement un oracle formel dans l’un ou l’autre de ces sens. Il ne fait pas partie d’un modèle de preuve et n’est pas une primitive cryptographique clairement bornée.

Mais du point de vue de l’ingénierie, il fonctionne souvent comme un oracle en pratique :

• on pose une question
• on reçoit une réponse plausible
• l’intérieur du système reste largement opaque
• la réponse peut être utile sans être digne de confiance

Ce dernier point est le plus important.

Pourquoi l’analogie de l’oracle est meilleure

Le modèle de l’oracle dirige l’attention vers les bonnes questions d’ingénierie.

Le modèle est opaque. Même lorsque nous savons quelque chose des données d’entraînement, de la récupération de contexte, des outils ou de la conception globale du système, nous n’avons généralement pas d’explication fiable pour savoir pourquoi telle réponse précise est apparue.

Les réponses peuvent être précieuses, mais elles ne sont pas garanties correctes. Elles peuvent être incomplètes, excessivement sûres d’elles, sensibles au contexte ou subtilement fausses, et ce type d’erreur est souvent découvert tard.

Cela signifie que les sorties doivent être traitées comme des hypothèses et non comme des faits.

Cela signifie aussi que la vérification n’est pas une étape finale. Elle fait partie du flux de travail lui-même.

Le véritable changement culturel se trouve là. Le problème n’est pas que les ingénieurs aient besoin de meilleures techniques de prompting. Le problème est que beaucoup d’équipes manquent encore d’une culture solide de la vérification pour le travail assisté par l’IA.

Culture de la vérification, pas culture du prompting

Le prompting compte, mais ce n’est pas le cœur du problème.

Une question étroite et bien bornée est utile parce qu’elle rend la vérification plus facile.

Un prompt trop large est dangereux parce qu’il encourage une confiance excessive dans la réponse.

Si une équipe considère l’interaction avec l’IA avant tout comme une compétence de prompting, elle optimisera généralement pour :

• la fluidité
• la vitesse
• un ton assuré
• une impression d’exhaustivité

Si elle considère l’IA comme l’usage d’un oracle, elle optimisera plutôt pour :

• des questions claires
• un périmètre limité
• des hypothèses explicites
• des vérifications indépendantes
• des justifications conservées
• une validation reproductible

La seconde liste est beaucoup plus proche de la véritable discipline d’ingénierie.

Ce que cela donne en pratique

Développement piloté par les spécifications

Le développement piloté par les spécifications part déjà du principe qu’une sortie rapide n’est pas la même chose qu’une sortie correcte. Une spécification écrite définit le but, les limites, les flux de travail et les critères d’acceptation avant qu’une sortie générée soit considérée comme une modification valable.

Voilà la discipline de l’oracle. La réponse doit être vérifiée par rapport à un standard défini à l’avance.

Travail de connaissance assisté par l’IA

Le travail de connaissance assisté par l’IA devient plus fiable lorsqu’il existe autour du modèle des éléments conservés dans le temps, une relecture explicite et des standards vérifiables. Une simple conversation n’est pas une source de vérité stable.

Gouvernance de la documentation

Les bonnes équipes séparent la spécification produit, les consignes d’implémentation, la documentation publique, les cartes de sources et les artefacts générés. Cette séparation évite qu’une réponse plausible ne devienne silencieusement une vérité admise.

Validateurs et tests

Les équipes ajoutent des validateurs parce que la mémoire et l’excès de confiance sont des contrôles faibles. Vérifications de liens, vérifications structurelles, contrôles de parité, génération de métadonnées, tests et validateurs de publication transforment la vérification en infrastructure.

Préserver le contexte et la justification

Une réponse utile de l’oracle ne suffit pas à elle seule. Si le travail doit survivre au temps et aux changements d’équipe, les hypothèses, preuves, notes de relecture et raisons d’accepter ou de rejeter la réponse doivent rester visibles.

Localisation et parité sémantique

La localisation est un bon exemple de l’importance de la vérification. Une traduction peut sembler fluide et pourtant échouer sur la modalité, la terminologie, la correction Unicode, le texte d’accessibilité ou la parité sémantique avec la source. Dans ce flux, la sortie de l’IA n’est pas une version prête à publier. C’est un brouillon à relire.

Exemples concrets

Le modèle de l’oracle devient plus clair lorsque les questions deviennent concrètes.

Demander à l’IA d’expliquer du code

Un LLM peut expliquer rapidement une fonction, un flux de données ou un bug de manière cohérente.

À vérifier :

• la correspondance avec le véritable chemin du code
• l’absence de cas limites oubliés
• la distinction entre comportement actuel et comportement visé
• la prise en compte des spécifications, tests ou commentaires autour du code

Vérification utile :

• lire le code concerné
• comparer la réponse aux tests existants
• vérifier si l’explication correspond au flux documenté

Demander à l’IA d’écrire un validateur

Un LLM peut produire un validateur qui paraît propre et convaincant.

À vérifier :

• qu’il contrôle bien la règle réelle
• qu’il ne crée pas un faux sentiment de sécurité
• qu’il ne manque pas des cas d’échec importants
• qu’il encode correctement la règle documentée

Vérification utile :

• créer des cas de test positifs et négatifs
• exécuter le validateur contre des échecs connus
• vérifier s’il protège réellement la classe de défaut visée

Demander à l’IA de traduire de la documentation

Un LLM peut produire rapidement une traduction soignée.

À vérifier :

• la parité sémantique avec la source
• la cohérence terminologique
• la correction de l’écriture et d’Unicode
• les éléments d’accessibilité
• l’alignement des exemples, liens et supports annexes

Vérification utile :

• lancer les validateurs de localisation et de parité
• comparer la structure des sections entre source et cible
• demander une relecture de locuteurs natifs pour les contenus importants

Demander à l’IA de proposer une architecture

Un LLM peut proposer une architecture en couches, une décomposition en services ou un schéma d’intégration qui semble raisonnable.

À vérifier :

• l’adéquation avec le périmètre réel du produit
• le respect des contraintes non négociables
• l’absence de complexité inutile
• l’absence d’hypothèses irréalistes sur l’infrastructure, le budget ou la maturité opérationnelle

Vérification utile :

• comparer la proposition à la spécification produit
• la tester contre les limites de périmètre et les critères d’acceptation
• noter les compromis avant adoption

À quoi ressemble la vérification en pratique

La vérification ne signifie pas toujours preuve formelle. Dans le travail réel d’ingénierie, elle consiste le plus souvent à combiner plusieurs contrôles plus faibles mais utiles.

• comparer la réponse à la spécification
• lire les fichiers concernés
• exécuter les tests
• lancer les validateurs
• vérifier les liens et les artefacts générés
• conserver les notes de relecture et les justifications
• poser une question de suivi plus étroite lorsque la première réponse est trop large

Voilà pourquoi la culture de la vérification passe mieux à l’échelle que la seule habileté de prompting. Elle crée des points de contrôle réutilisables qui survivent aux conversations individuelles.

Enseignement pratique

• Poser des questions étroites.
• Noter les hypothèses.
• Vérifier les affirmations.
• Utiliser tests et validateurs.
• Préserver les justifications.
• Traiter la sortie de l’IA comme un élément de preuve, pas comme la vérité.

En conclusion

L’IA n’est ni un collègue ni un moteur de recherche.

Elle ressemble davantage à un oracle : une boîte noire capable de répondre à des questions remarquablement difficiles, à condition de poser la question avec soin et de vérifier la réponse.

Le défi de l’ingénierie assistée par l’IA n’est pas d’apprendre à utiliser l’oracle. C’est d’apprendre à ne pas lui faire trop confiance.

Lectures liées

• ../../wiki/ai-assisted-knowledge-work.md
• ../../wiki/spec-driven-development.md
• ../../wiki/validation-layers.md
• ../../wiki/documentation-traceability.md
• ../../wiki/localization-governance.md
• ../../wiki/let-books-localization-case-study.md
• ai-workflows-beyond-software.md
• spec-driven-development-for-ai-projects.md
• documentation-is-part-of-the-product.md