Réponse courte : un pilote IA de trente jours ne doit pas chercher à prouver que l'outil fonctionne. Il doit permettre une décision documentée : arrêter, corriger, prolonger le test ou déployer progressivement. Pour y parvenir, figez avant le jour 1 une référence mesurée, un échantillon représentatif, une grille de qualité, des garde-fous et des seuils d'arrêt. Testez ensuite hors production, en mode silencieux puis sur un périmètre assisté, sans jamais laisser le gain de temps compenser une erreur critique.
Trente jours suffisent pour comparer un processus actuel à une solution limitée. Ils ne suffisent pas pour démontrer la sécurité de tous les usages futurs, ni pour transformer un prototype en système de production. Le résultat attendu est un dossier de décision reproductible, pas une démonstration séduisante.
Avant le jour 1 : signer un contrat de pilote d'une page
Le cas d'usage doit déjà avoir été choisi. Si l'équipe hésite encore entre plusieurs tâches, commencez par la méthode pour choisir le premier cas d'usage IA. Le pilote décrit ici commence lorsqu'une tâche précise, un responsable et une sortie vérifiable existent.
Le contrat de pilote tient sur une page et ne change plus après le lancement sans laisser une trace. Il contient neuf décisions :
- Tâche : une entrée, une opération et une sortie observables, par exemple « préparer un brouillon de réponse support à partir de la documentation autorisée ».
- Périmètre : utilisateurs, langues, volumes, canaux, catégories incluses et cas explicitement exclus.
- Référence : délai, effort, coût et qualité du processus actuel sur une période datée.
- Échantillon : nombre de cas, méthode de sélection et représentation des cas fréquents, rares et graves.
- Qualité : critères, échelle de notation, erreurs critiques et personne chargée de trancher les désaccords.
- Garde-fous : données autorisées, accès, journalisation, supervision humaine, actions interdites et procédure de retour manuel.
- Seuils : résultats minimaux pour poursuivre et événements qui suspendent immédiatement le test.
- Ressources : responsable métier, référent données ou conformité, responsable technique, évaluateurs, budget et temps maximal.
- Décision : comité, date du jour 30 et quatre issues possibles : arrêter, corriger, prolonger ou déployer par étapes.
Le NIST organise la gestion des risques autour de quatre fonctions continues : govern, map, measure, manage. Dans un pilote court, elles deviennent respectivement : nommer qui décide, documenter le contexte, mesurer sur des cas proches de l'usage réel, puis traiter ou refuser les risques observés. Le cadre est volontaire ; il ne remplace pas les obligations juridiques applicables.
Le plan exécutable, du jour 1 au jour 30
Le calendrier suivant suppose que les accès et le responsable métier sont disponibles. Un jour bloqué n'est pas « rattrapé » en supprimant l'évaluation : le pilote glisse ou s'arrête. Chaque phase se termine par une preuve conservée.
| Période | Travail à réaliser | Livrable exigé | Condition pour continuer |
|---|---|---|---|
| J1–J2 | Observer le processus actuel, mesurer le temps actif, les reprises et la qualité sans IA. | Baseline datée et définitions des mesures | Les données de référence sont exploitables et le responsable métier les reconnaît. |
| J3 | Définir la grille de qualité et annoter les mêmes cas à deux évaluateurs. | Rubrique, exemples et règle d'arbitrage | Les évaluateurs comprennent les critères de la même manière. |
| J4–J5 | Construire l'échantillon, vérifier les droits sur les données, supprimer les champs inutiles et figer les seuils. | Registre d'échantillon et contrat signé | Aucune donnée ni catégorie critique n'entre sans justification et contrôle. |
| J6–J8 | Construire la version minimale sur données fictives, synthétiques, anonymisées ou préalablement autorisées. | Prototype isolé et versionné | Aucune action externe automatique ; les entrées, sorties et versions sont traçables. |
| J9–J10 | Ajouter filtrage, contrôle d'accès, journal, bouton d'arrêt et retour au processus manuel ; répéter un incident. | Procédure d'exploitation et compte rendu d'exercice | L'équipe sait suspendre le pilote et reprendre sans perte ni double traitement. |
| J11–J13 | Tester hors production sur un premier lot annoté, sans montrer aux évaluateurs quelle réponse vient de l'IA. | Résultats par strate et liste d'erreurs | Aucune erreur critique ; les erreurs majeures ont une cause et un traitement. |
| J14–J15 | Tester cas limites, instructions contradictoires, documents incomplets, données sensibles et indisponibilité du fournisseur. | Registre des défaillances et revue intermédiaire | Le comité autorise le mode silencieux ou ordonne une correction. |
| J16–J18 | Faire tourner le système en mode silencieux : il produit une sortie, mais le processus réel ne la voit pas et continue normalement. | Comparaison IA/réalité sur des cas récents | La distribution réelle ressemble à l'échantillon et les garde-fous tiennent. |
| J19–J22 | Ouvrir à quelques utilisateurs formés, uniquement en aide à la décision ou en brouillon avec validation préalable. | Journal des acceptations, corrections, rejets et temps de revue | Le gain reste positif après contrôle humain et la qualité ne recule pas. |
| J23–J24 | Augmenter le lot sans élargir les usages, les données ou les droits ; surveiller les mêmes mesures. | Mesures stabilisées et analyse des sous-groupes | Aucune strate ne masque une dégradation derrière la moyenne. |
| J25–J27 | Tester quota, panne, sortie invalide, retrait d'accès et suppression des données ; chiffrer revue et exploitation. | Test de repli, inventaire des données et coût observé | Le processus manuel reprend, les données sont maîtrisées et le budget reste sous plafond. |
| J28–J29 | Geler le système, recalculer les résultats, faire rejouer un lot par une personne non impliquée dans la construction. | Dossier de preuve et limites connues | Les résultats sont reproductibles et les exceptions non résolues sont visibles. |
| J30 | Comparer les résultats aux seuils écrits et prendre une décision sans modifier les critères après coup. | Procès-verbal : arrêt, correction, prolongation ou déploiement progressif | Chaque conclusion renvoie à une mesure, un incident ou une preuve. |
Construire une baseline que l'IA ne peut pas embellir
La référence décrit le processus avant l'IA. Mesurez-la sur la même unité que le pilote : un ticket, une facture, un dossier ou une réponse. Le temps calendaire seul est trompeur ; séparez le temps actif de travail, le temps d'attente et les reprises.
| Mesure | Définition à figer | Pourquoi elle compte |
|---|---|---|
| Temps actif médian | Minutes réellement consacrées au cas, corrections comprises | Évite qu'une moyenne soit déformée par quelques cas extrêmes. |
| Qualité acceptable | Part des cas qui franchissent la grille sans erreur majeure ou critique | Empêche de gagner du temps en déplaçant les erreurs vers l'aval. |
| Reprise | Part des cas rouverts, corrigés intégralement ou retournés | Révèle les coûts qui apparaissent après la première sortie. |
| Effort de contrôle | Minutes de vérification et de correction par sortie IA | Mesure le travail humain créé par le système. |
| Erreur critique | Événement défini à l'avance : fuite, action interdite, décision non réversible ou contenu dangereux | Déclenche l'arrêt indépendamment des moyennes. |
| Coût marginal | Modèle, recherche, stockage, intégration et supervision par cas | Évite de confondre prix d'appel et coût du processus testé. |
Conservez les observations brutes, la période et les règles d'exclusion. Si la baseline a été mesurée pendant un mois exceptionnel, ajoutez une seconde période ou notez la limite. La comparaison n'est crédible que si le pilote traite un mélange de cas comparable.
Une formule simple aide à détecter le déplacement de travail :
gain net par cas = temps actuel − temps assisté − temps de revue − temps de correction
Le gain financier peut ensuite multiplier ce temps par un coût horaire explicite et retrancher le coût marginal du système. Dans un pilote de trente jours, cette estimation reste une observation locale, pas une promesse annuelle.
Composer l'échantillon par risque, pas par facilité
Prendre les cent derniers dossiers au hasard peut oublier les cas rares qui produisent les dommages les plus graves. Construisez d'abord des strates, puis tirez des cas dans chacune. Au minimum, distinguez le flux fréquent, les variantes connues, les entrées dégradées et les cas à impact élevé.
| Strate | Exemples | Rôle dans le pilote |
|---|---|---|
| Courante | Langue principale, format standard, données complètes | Mesurer le gain sur le travail majoritaire |
| Variante métier | Produit, client, équipe ou règle moins fréquente | Vérifier que la moyenne ne masque pas un sous-groupe faible |
| Entrée dégradée | Document incomplet, scan médiocre, demande ambiguë | Tester l'abstention, l'escalade et le comportement hors confiance |
| Cas limite | Instruction contradictoire, requête inhabituelle, contenu hors périmètre | Chercher les défaillances avant l'ouverture |
| Impact élevé | Donnée sensible, montant important, personne vulnérable, effet juridique | Décider s'il faut exclure le cas ou imposer un contrôle renforcé |
Surreprésenter les strates rares est utile pour chercher des défaillances, mais déforme la moyenne si l'on traite ensuite chaque cas comme s'il avait la même fréquence en production. Avant le premier test, figez donc le poids opérationnel de chaque strate à partir d'une période de référence : par exemple 65 % de cas courants, 20 % de variantes métier, 10 % d'entrées dégradées, 4 % de cas limites et 1 % de cas à impact élevé. Le lot de test peut volontairement contenir 10 % de cas à impact élevé ; son poids dans l'agrégat reste 1 % si ce chiffre décrit le mix réel.
Publiez toujours deux lectures : les résultats bruts de chaque strate — avec leur effectif, leur qualité et leurs erreurs — puis l'agrégat recalculé selon les poids opérationnels figés. Pour un taux, utilisez taux pondéré = somme(taux de la strate × poids opérationnel). Pour une médiane de temps, ne faites pas la moyenne des médianes : repondérez les observations ou présentez les distributions et quantiles par strate. Ne comparez jamais la moyenne non pondérée d'un échantillon surreprésentant les risques à la baseline opérationnelle. Si le mix réel est mal connu, le résultat global reste indéterminé ; conservez alors les résultats par strate et prolongez la mesure.
Le nombre de cas dépend du volume et de la précision recherchée. Pour estimer un taux avec un échantillon aléatoire simple, l'approximation n = p × (1 − p) × (1,96 / marge)^2 donne environ 96 cas pour une marge de dix points lorsque le taux attendu est inconnu et fixé prudemment à 50 %, et environ 385 cas pour cinq points. Cette formule n'annule ni les biais de sélection, ni la dépendance entre cas, ni le besoin de surreprésenter des risques rares. Pour un usage à fort impact, faites définir le protocole par des compétences statistiques et métier adaptées.
Réservez une partie des cas jusqu'à la fin. L'équipe qui règle le prototype ne doit pas voir tout le jeu d'évaluation. Faites aussi noter au moins 20 % du lot par deux évaluateurs ; un désaccord fréquent signale souvent une grille ambiguë, pas un problème de modèle.
Noter la qualité et la gravité séparément
Une note globale de satisfaction ne suffit pas. Utilisez une rubrique courte, propre à la tâche, avec des exemples de score. Pour un brouillon fondé sur des documents, la grille suivante peut servir de départ :
| Critère | 0 | 1 | 2 |
|---|---|---|---|
| Exactitude | Affirmation fausse ou inventée | Imprécision sans effet majeur | Conforme aux éléments disponibles |
| Couverture | Omet l'objet principal | Réponse partielle | Traite tous les éléments requis |
| Preuve | Source absente ou trompeuse | Source pertinente mais incomplète | Source précise et vérifiable |
| Respect des règles | Action ou contenu interdit | Écart formel corrigeable | Périmètre et consignes respectés |
| Utilité | Sortie inutilisable | Révision substantielle nécessaire | Utilisable après contrôle normal |
Ajoutez une classification de gravité qui prime sur le score :
- Critique : donnée divulguée, action non autorisée, conseil dangereux, montant ou identité erroné avec effet, impossibilité de reprendre manuellement.
- Majeure : réponse fausse ou incomplète qui exige une reprise substantielle avant usage.
- Mineure : formulation, format ou détail corrigeable sans changer la décision.
Le profil GenAI du NIST recommande de mesurer les performances dans des conditions proches du déploiement, de documenter les mesures et de partager les résultats des tests préalables avec l'autorité qui décide de la mise en service. Il souligne aussi les limites des tests déconnectés du contexte réel. C'est la raison du passage successif hors production, en mode silencieux puis en assistance contrôlée.
Installer les garde-fous avant d'observer le premier gain
Les protections ne sont pas une phase finale. Elles déterminent ce que le pilote a le droit de faire :
- aucun envoi, paiement, rejet, mise à jour de référentiel ou décision externe sans validation humaine explicite ;
- liste fermée des sources, des utilisateurs et des catégories de données autorisés ;
- suppression ou masquage des champs inutiles avant l'appel au système ;
- journal de la version, de l'entrée autorisée, de la sortie, de la correction et de la décision humaine ;
- bouton d'arrêt testé, propriétaire joignable et procédure manuelle disponible ;
- plafond de coût, de volume et de durée ;
- interdiction de réutiliser les données du pilote pour entraîner ou améliorer un service sans décision distincte ;
- durée de conservation et suppression de fin de pilote définies avant la collecte.
Lorsque des données personnelles sont utilisées, la CNIL demande une finalité déterminée, explicite et légitime, puis des données adéquates, pertinentes et limitées à ce qui est nécessaire. Elle distingue également développement et production. Sa liste de vérification recommande notamment de justifier les sources et volumes, de privilégier quand c'est possible un pilote avec des données fictives, synthétiques ou anonymisées, puis d'organiser la suppression ou l'archivage en fin de phase.
Une analyse d'impact sur la protection des données peut être nécessaire. La CNIL la recommande fortement lorsque plusieurs critères de risque sont réunis — données sensibles, grande échelle, personnes vulnérables, croisements de données ou usage innovant — et l'estime en principe nécessaire pour les systèmes à haut risque impliquant des données personnelles. Un pilote court ne suspend pas cette analyse.
Écrire les seuils d'arrêt avant le test
Les seuils ci-dessous sont un exemple de contrat pour un brouillon support à faible impact, pas une norme générale. Un cas médical, financier, social ou lié à l'emploi peut exiger l'arrêt à la première erreur d'une catégorie beaucoup plus large.
| Signal | Seuil pédagogique | Action |
|---|---|---|
| Donnée personnelle envoyée hors du périmètre autorisé | Un événement | Arrêt immédiat, confinement, analyse et décision conformité |
| Action externe interdite ou contournement de la validation | Un événement | Arrêt immédiat et retour manuel |
| Erreur critique de contenu | Une erreur non contenue, ou deux sur cinquante cas même si elles sont interceptées | Suspendre et corriger avant tout nouveau lot |
| Qualité acceptable | Plus de trois points sous la baseline après cent cas revus | Refuser l'élargissement et analyser par strate |
| Erreurs majeures | Plus de 10 % après cent cas revus | Corriger la cause, constituer un nouveau lot et retester |
| Gain net | Nul ou négatif après revue et correction | Arrêter ou redessiner la tâche |
| Coût ou volume — alerte | 80 % du plafond contractuel | Geler toute augmentation, prévoir la consommation finale et réduire le lot si nécessaire |
| Coût ou volume — arrêt | 100 % du plafond contractuel | Arrêter automatiquement le pilote ; aucun dépassement n'est autorisé |
Le NIST recommande de relier les décisions de mise en service aux capacités mesurées, aux risques et à la tolérance de l'organisation, puis de définir des critères de désactivation. Un seuil utile indique donc une mesure, une fenêtre, une personne autorisée et l'action immédiate. « Trop d'erreurs » n'est pas un seuil.
Exemple chiffré : préparer des brouillons pour le support
L'exemple suivant est fictif et sert à montrer le protocole. Une équipe traite environ 1 200 demandes par mois. Le système proposé retrouve des passages dans une documentation approuvée et prépare un brouillon ; l'agent peut accepter, corriger ou rejeter. Aucun message ne part automatiquement.
Sur 200 demandes historiques stratifiées, la baseline donne 12,4 minutes de travail médian, 91 % de réponses acceptables selon la grille, 7 % de réouvertures et aucune erreur critique. L'équipe réserve ensuite 240 cas au pilote : 80 pour le test hors production, 80 pour le mode silencieux et 80 pour l'assistance contrôlée. Chaque lot contient demandes courantes, facturation, accès, documents incomplets et cas hors périmètre. Les catégories rares sont surreprésentées pour le test, tandis que les poids du mix réel, figés à partir de la baseline, servent seuls au calcul des taux agrégés.
Le contrat exige au jour 30 :
- un temps humain médian inférieur ou égal à 9,3 minutes, soit au moins 25 % de réduction ;
- une qualité acceptable au moins égale à 91 % ;
- un taux de réouverture inférieur ou égal à 7 % ;
- aucune erreur critique et au plus 10 % d'erreurs majeures ;
- 100 % des brouillons relus avant envoi pendant tout le pilote ;
- une reprise manuelle testée en moins de quinze minutes ;
- un coût total par demande inférieur au plafond fixé dans le contrat.
Si le temps tombe à huit minutes mais que la qualité descend à 86 %, le pilote échoue : le gain ne rachète pas la dégradation. Si la qualité atteint 93 % mais que la revue prend treize minutes, le système ne crée pas encore de gain opérationnel. Si les résultats globaux passent mais que la facturation concentre les erreurs majeures, l'équipe peut exclure cette strate et décider uniquement pour les autres.
Jour 30 : quatre décisions possibles, aucune cinquième
| Décision | Quand la prendre | Suite autorisée |
|---|---|---|
| Arrêter | Erreur critique, absence de gain net, données non maîtrisées ou processus manuel plus simple | Désactiver, supprimer selon la politique, documenter ce qui a été appris |
| Corriger et retester | Cause précise et corrigeable, mais seuil de qualité ou de coût non atteint | Nouveau lot réservé et nouveau délai ; aucun passage implicite en production |
| Prolonger la mesure | Résultats proches des seuils mais incertains, volume trop faible ou strate saisonnière absente | Même périmètre, critères inchangés et date de décision supplémentaire |
| Déployer progressivement | Tous les seuils sont franchis, les incidents sont maîtrisés et le repli fonctionne | Ouverture par strate ou équipe avec supervision, suivi et critères de désactivation conservés |
Le dossier final contient le contrat initial, les versions testées, la baseline, la composition de chaque lot, les annotations, les désaccords, les incidents, les coûts, les exclusions et les résultats par strate. Il indique aussi ce que le pilote n'a pas prouvé : performance à une autre langue, autre volume, autre équipe, autre modèle ou autre type de données.
La meilleure issue n'est pas forcément le déploiement. Un arrêt fondé sur des mesures évite de transformer un doute en dette opérationnelle. Un déploiement, lui, ne devient défendable que si le système peut être surveillé, repris et désactivé avec les mêmes exigences que pendant le pilote.
Sources officielles consultées
- NIST — AI Risk Management Framework, consulté le 29 juillet 2026 ; le NIST précise que l'AI RMF 1.0 est en cours de révision.
- NIST AI Resource Center — AI RMF Core : Govern, Map, Measure, Manage, consulté le 29 juillet 2026.
- NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, juillet 2024 ; page de publication mise à jour le 8 avril 2026.
- CNIL — Développement des systèmes d'IA : les recommandations pour respecter le RGPD, 22 juillet 2025.
- CNIL — Développement des systèmes d'IA : que faut-il vérifier ?, liste pratique publiée en juillet 2025.
- CNIL — IA : comment être en conformité avec le RGPD ?, consulté le 29 juillet 2026.