Une IA qui tient en dehors de la démo.

• Une fonctionnalité d'IA qui marche en démo et à laquelle on n'a pas encore confié de vrais utilisateurs.
• Un agent qui doit agir dans de vrais systèmes, où la question est ce qu'il ne doit jamais pouvoir faire.
• Un workflow comportant une vraie répétition, où le jugement reste à une personne mais où la mécanique ne devrait pas lui revenir.
• Une surface d'IA existante dont le comportement change de façon imprévisible quand un prompt ou un modèle est mis à jour.
• Un produit où la qualité de la recherche documentaire, et non le choix du modèle, décide réellement si les réponses sont bonnes.

Une architecture de référence, c'est-à-dire la forme sur laquelle le travail est conçu, et non un relevé de systèmes livrés. Elle nomme des couches et des responsabilités, jamais des produits : ce qui tourne à une couche donnée est une décision prise avec vous pendant le cadrage, pas ici à l'avance.

• L'orchestration d'agents et de workflows : les étapes, l'état entre elles, et ce qui se passe quand l'une échoue.
• Des limites explicites d'outils et de permissions : ce que le système peut lire, écrire et appeler, décidé et écrit.
• Une conception du contexte et de la recherche documentaire, construite sur les questions auxquelles le système doit réellement répondre.
• Un plan et un banc d'évaluation : les cas sur lesquels il est mesuré, et la procédure pour vérifier un changement avant sa mise en production.
• Des garde-fous et des chemins de défaillance définis, y compris ce que fait le système quand il n'est pas sûr de lui.
• La circulation des données entre les systèmes touchés, avec des frontières franchies de façon délibérée.

• Livrer un changement sur une surface d'IA parce qu'il avait meilleure allure en démo.
• Un agent qui peut atteindre un système que personne n'avait prévu qu'il atteigne, parce qu'il a hérité d'un identifiant au lieu de se le voir accorder.
• Un comportement qui change sans prévenir quand une version de modèle évolue sous vos pieds.
• Un chemin de défaillance découvert par un utilisateur plutôt que conçu par un ingénieur.
• Une automatisation qui déplace le travail ailleurs au lieu de le supprimer.

• Une démo destinée à lever des fonds plutôt qu'à servir des utilisateurs. C'est une envie légitime, et ce n'est pas ce dont il s'agit ici.
• L'entraînement ou le fine-tuning de modèles comme sujet principal. Le travail ici est le système autour du modèle ; quand un fine-tuning est réellement la réponse, cela se dit pendant le cadrage.
• Une fonctionnalité d'IA sans condition de réussite définie, où personne ne sait dire à quoi ressemble une bonne réponse. C'est une question de produit, et elle vient d'abord.
• Remplacer un jugement qui doit rester à une personne. L'automatisation vise la mécanique répétitive, pas la décision.
• Tout ce qui exige de publier un chiffre de benchmark avant que le système existe pour être mesuré.

1. 01

   Le plan d'évaluation, et le banc qui l'exécute

   Ce que le système a le droit de faire, ce qu'il ne doit jamais faire, les cas sur lesquels il est mesuré, et la procédure pour vérifier un changement de prompt ou de modèle. Votre équipe l'exécute après notre départ ; c'est tout son intérêt.

2. 02

   Le modèle de permissions, écrit

   Ce que chaque agent, tâche et intégration peut lire, écrire et appeler, et pourquoi. Un contrôle que l'on peut relier à sa raison peut être revu. Un contrôle que l'on ne peut pas relier est deviné, puis finit par être élargi.

3. 03

   Les prompts et le contexte dans les sources

   Versionnés dans vos dépôts à côté du code, pas collés dans une console. Un prompt est une décision de comportement, et il relève de la même revue que n'importe quelle autre.

4. 04

   Les limites connues

   Où le système est faible, quelles entrées il traite mal, et ce qui a été volontairement laissé hors périmètre. Énoncé clairement, parce que l'alternative est que votre équipe les redécouvre une à une.

• DocumentsExemples de livrablesLe plan d'évaluation de l'IA est l'un des huit formats, présenté avec ce qu'il consigne et le risque qu'il écarte.
• RéalisationUn système d'analyse en langage naturelLa réalisation données et inférence : mener des événements bruts jusqu'à un chiffre sur lequel agir, sans défaillance silencieuse.
• ServiceSécurité et profondeur systèmeLà où le travail sur les limites des agents se poursuit : moindre privilège, gestion des identifiants et rayon d'impact d'une erreur.