# Du pilote IA à la production : un modèle neutre | tracee > Une architecture de référence neutre pour l'IA en production et ses tests d'acceptation : précision, erreurs, délai, coût par dossier, pannes et retour arrière. Source: https://traceegroup.com/fr/ia/analyses/pilote-production --- # Du pilote IA à la production. Le modèle n'est qu'une couche sur quatre. ## Un pilote prouve qu'un modèle sait faire une tâche. La production prouve qu'on peut s'y fier. Un pilote montre qu'un modèle sait accomplir une tâche sur des exemples préparés. La production montre qu'une organisation peut en dépendre chaque jour, avec des défaillances visibles, contenues et réversibles. L'écart entre les deux tient rarement au modèle. Il tient à l'architecture, aux tests et à l'exploitation, et il peut être spécifié à l'avance. - Architecture de référence - Tests d'acceptation - Après la mise en service - Contexte réglementaire - Limites ## Quatre couches, versionnées de bout en bout. L'architecture est neutre vis-à-vis des fournisseurs : n'importe quel fournisseur de modèle, ou un modèle auto-hébergé, peut se placer derrière. Son objet est de garder le modèle remplaçable et ses résultats vérifiables. Du pilote à la production · Architecture de référence ### Quatre couches, dont une seule est le modèle. Faites défiler le schéma latéralement pour le voir en entier. **Lire le schéma sous forme de texte** - L'application existante reste le système de référence. Elle confie un dossier au workflow et ne reçoit en retour que des écritures validées. - La logique de workflow est un logiciel déterministe ordinaire : elle enchaîne les étapes, applique les règles, conserve l'état, reprend sans risque et garantit l'idempotence. - La brique IA contrôlée est la passerelle unique vers tout modèle : gabarits de prompts versionnés, filtrage des entrées, validation du schéma de sortie, plafonds de débit et de coût, abstraction du fournisseur. - Le modèle lui-même est un service fournisseur ou un modèle auto-hébergé, interchangeable derrière la passerelle. - Propositions et preuves vont à la boucle de revue : une file, des décisions, des corrections et les preuves conservées. Les décisions reviennent au workflow. - Supervision et gestion des versions couvrent la chaîne : qualité, délai, coût, taux de correction et dérive sont mesurés ; prompts, modèles, règles, index et jeux d'évaluation sont versionnés. L'application existante reste le système de référence. L'IA n'y écrit jamais directement. La logique de workflow est un logiciel déterministe ordinaire qui enchaîne les étapes, applique les règles, conserve l'état et garantit qu'une reprise n'agit jamais deux fois. La brique IA contrôlée est la passerelle unique pour tout appel de modèle : gabarits de prompts versionnés, filtrage des entrées, validation du schéma de sortie, plafonds de débit et de coût, et une abstraction qui permet de changer de fournisseur. La boucle de preuve et de revue présente les propositions aux personnes avec leurs éléments, et enregistre ce qu'elles décident. Sur toute la chaîne s'étendent la supervision (qualité, délai, coût par dossier, taux de correction, dérive) et la gestion des versions de tout composant capable de changer le comportement : prompts, modèles, règles, index de recherche et jeux d'évaluation eux-mêmes. ## Sept tests, des seuils écrits avant l'exécution. Chaque test a une mesure et un seuil convenus avec le responsable du processus avant le début des tests. Fixer les seuils après avoir vu les résultats, c'est ainsi que des systèmes fragiles sont validés. - Test - Ce qui est mesuré - Comment fixer le seuil - Précision sur cas annotés - Précision et rappel, par champ ou par décision, sur un jeu mis de côté qui reflète le volume réel, cas difficiles compris. - Par rapport au taux d'erreur manuel mesuré, champ par champ. - Charge des faux positifs et faux négatifs - Combien d'éléments sont signalés à tort (temps de revue) et combien passent à tort (coût en aval). - Selon la capacité de revue et le coût d'une erreur non détectée. Les deux sont arbitrés explicitement. - Délai de réponse - Délai de bout en bout à la médiane et au 95e centile, reprises comprises. - Selon le processus : traitement de nuit, ou client qui attend. - Coût par dossier - Appels au modèle, infrastructure et temps de revue par dossier. - Inférieur au coût de référence par dossier, au volume attendu. - Pannes et reprises - Délais dépassés, sorties malformées, doublons et panne du fournisseur provoqués volontairement. - Aucune écriture partielle, aucune action en double, chaque dossier en échec visible dans une file. - Confidentialité - Contenu réel envoyé au modèle, contenu des journaux, réglages de conservation, droits de recherche testés avec des comptes de test. - Seuls les champs spécifiés quittent l'application ; aucun utilisateur ne retrouve un document qu'il ne peut pas ouvrir. - Retour arrière - Retour répété à la version précédente, et au traitement manuel. - Réalisé dans un délai convenu, sans dossier perdu. Aucun test ne rend un système sûr dans l'absolu. Réussir ces tests montre que les risques mesurés restent dans des limites que vous avez choisies, sur les cas testés. La production apporte des cas non testés. La supervision sert à les trouver. ## Chaque changement rejoue le jeu d'évaluation. - Le taux de correction est le meilleur signal précoce. Quand les relecteurs corrigent davantage, quelque chose a dérivé : les entrées, le modèle ou le processus. - Une revue par échantillon des éléments acceptés, pas seulement des éléments signalés, repère les erreurs assurées qui n'atteignent jamais une file. - La maîtrise des changements : toute modification d'un prompt, d'une version de modèle, d'une règle ou d'un index rejoue le jeu d'évaluation, et le résultat est rangé dans le registre des versions avant la mise en ligne. - Les changements du fournisseur comptent comme des changements. Une version de modèle retirée ou mise à jour par le fournisseur déclenche le même rejeu. - Une réévaluation périodique ajoute de nouveaux cas annotés issus des corrections, pour que le jeu de test suive la réalité. ## La bonne ingénierie d'abord ; la qualification juridique confirmée à part. Si un système relève d'une catégorie à haut risque de l'AI Act, des obligations telles que la gestion des risques, la tenue de registres, le contrôle humain et la documentation de l'exactitude et de la robustesse s'appliquent. Selon la présentation de la Commission européenne, consultée le 22 octobre 2026, un règlement modificatif en vigueur depuis le 27 juillet 2026 a fixé l'application de ces obligations au 2 décembre 2027 pour les usages à haut risque de l'annexe III, et au 2 août 2028 pour l'IA intégrée à des produits réglementés. De nombreux workflows opérationnels de PME, comme la réception de factures ou la recherche dans les documents internes, ne seront pas à haut risque. Mais la qualification dépend de la finalité du système et doit être confirmée avec un conseil, pas supposée. Les pratiques de ce guide relèvent de la bonne ingénierie dans tous les cas, et produisent une grande partie des éléments qu'un régime à haut risque exigerait. L'AI Risk Management Framework du NIST propose une structure volontaire pour ce même travail, autour de quatre fonctions : gouverner, cartographier, mesurer, gérer. ## Ce que ce guide ne fait pas. - Il ne constitue pas un conseil juridique et ne détermine pas si l'AI Act s'applique à votre système. - Les dates réglementaires ci-dessus proviennent de la présentation de la Commission à la date indiquée et peuvent évoluer ; vérifiez la source. - Il ne prescrit pas de seuils. Ils dépendent du processus, de son volume et du coût des erreurs. - Il traite des workflows d'aide à la décision avec revue humaine, pas de systèmes entièrement autonomes. - NISTAI Risk Management Framework, AI RMF 1.0 (en anglais), publié le 26 janvier 2023. - NISTGenerative Artificial Intelligence Profile, NIST AI 600-1 (en anglais), publié le 26 juillet 2024. - Commission européenneAI Act : cadre réglementaire de l'IA (en anglais). Consulté le 22 octobre 2026 pour le calendrier d'application. - CNILIntelligence artificielle : le guide, pour les aspects données personnelles des tests et de la journalisation. Ingénieur, titulaire d'un doctorat en informatique et systèmes de Sorbonne Université. Dirige le pôle IA appliquée. Profil complet.