Checklist de préparation IA avant déploiement

Une politique de gouvernance, à elle seule, est une promesse. Une checklist de préparation, c’est ce qui prouve que la promesse tient le jour où l’IA passe en production. La plupart des déploiements d’IA qui échouent en production n’échouent pas parce que le modèle était mauvais, mais parce que des questions opérationnelles basiques n’ont pas été tranchées avant le lancement : qui surveille le système, comment on l’éteint, quel est le repli quand il casse, et si les données qui entrent étaient réellement aptes à l’usage.

Cet article est une checklist de pré-déploiement utilisable telle quelle. Elle s’associe directement à l’article sur la gouvernance de l’IA, qui définit les règles que l’organisation choisit de tenir. La checklist ci-dessous est ce qui rend ces règles applicables en pratique, pour que le système qui passe en production le vendredi ne devienne pas silencieusement le problème de quelqu’un d’autre le lundi.

Le premier ensemble de filtres porte sur les données que le modèle va voir, pas sur le modèle lui-même. Trois vérifications attrapent l’essentiel des problèmes évitables.

La première est la couverture et la fraîcheur. Les données que le modèle utilisera à l’inférence représentent-elles vraiment les cas qu’il rencontrera en production ? Un modèle entraîné ou alimenté par des données vieilles de six mois, dans un domaine où le monde a bougé (nouveaux produits, nouvelle tarification, nouvelle réglementation), sera confiant et faux d’une façon difficile à repérer.

La deuxième, c’est le bruit et les labels. Pour les modèles prédictifs, les labels sont-ils fiables, ou sont-ils eux-mêmes la sortie d’un processus inconsistant en amont ? Pour les modèles génératifs avec récupération, le corpus source est-il propre, ou contient-il des doublons, des documents périmés et des versions contradictoires de la même politique ?

La troisième, c’est la donnée personnelle et la confidentialité. Quelqu’un a-t-il fait le tour de ce que le modèle touche, et de ce qui peut sortir de l’organisation via les sorties du modèle ou via les logs du fournisseur ? « Nous supposions que le modèle ne loguait pas ceci » est une cause récurrente d’incident post-lancement.

Si ces trois points ne sont pas tranchés par écrit avant le lancement, le système n’est pas prêt à être déployé, peu importe la qualité de la démo.

Un modèle dont la performance n’est pas mesurée contre une baseline claire ne peut pas être dit performant. Le mode d’échec le plus courant ici, c’est de lancer une fonctionnalité IA sans avoir jamais mesuré ce que faisait l’humain (ou le système hérité) dans le même workflow.

Deux artefacts ferment cet écart. D’abord, une métrique de baseline pour la tâche : le temps moyen de traitement, le taux de résolution, les heures de revue documentaire, l’exactitude des devis, avant que l’IA ne soit ajoutée. Sans elle, « l’IA a fait gagner du temps » est une affirmation, pas une mesure. Ensuite, un jeu de validation construit à partir de données réelles de l’organisation, avec un critère d’acceptation explicite : à quel niveau de qualité le modèle doit-il être sur ce jeu pour être autorisé en production, et comment cela est-il jugé.

Le jeu de validation est aussi ce qui rattrape la pire catégorie de régression : le modèle qui s’améliore en moyenne et se dégrade sur le petit nombre de cas à fort enjeu. Faire entrer délibérément ces cas dans le jeu de validation, plutôt que de se reposer sur la précision moyenne, est ce qui protège l’organisation de l’incident qui fait la une.

Tout système d’IA en production sera, à un moment, faux, lent ou indisponible. Trois décisions pré-lancement déterminent le coût de ce moment.

Le chemin de repli est ce qui se passe quand l’IA ne peut pas, ou ne doit pas, répondre. Un retour vers une file d’agents humains. Une heuristique plus simple. Un système hérité en lecture seule. Concevoir le repli avant le lancement (pas pendant l’incident) fait la différence entre une dégradation de cinq minutes et une indisponibilité d’une demi-journée.

Le plan de rollback est la manière dont l’organisation éteint l’IA, vite, si le comportement se dégrade. Cela inclut le pinning de versions précises de modèle quand le fournisseur le permet, le maintien du prompt ou du fine-tune précédent disponible, et la garantie que le rollback peut être déclenché par une personne d’astreinte sans passer par un processus de release. Les fournisseurs mettent à jour les modèles silencieusement. Le plan de rollback en tient compte.

Le bouton off est le plus simple et le plus souvent absent : une action unique, documentée, qui retire la fonctionnalité IA du flux utilisateur sans faire tomber le reste du produit. Si personne ne peut nommer qui a le bouton off et comment l’utiliser, le système n’est pas prêt.

Déployer de l’IA sans monitoring, c’est déployer n’importe quel autre système de production sans monitoring, et cela produit le même résultat quelques semaines plus tard. Quatre éléments doivent être en place.

Une vue de monitoring qui fait remonter la dérive d’entrée, la dérive de sortie (la distribution des réponses du modèle qui change dans le temps), la latence, le taux d’erreur et le taux de correction ou d’override par les humains. Le taux d’override, en particulier, est un signal d’alerte précoce que le modèle ne fait plus ce que les utilisateurs veulent.

Un propriétaire nommé de la fonctionnalité IA en production, avec un chemin d’escalade clair. « L’équipe qui l’a construite » n’est pas une réponse une fois que l’équipe est passée à l’initiative suivante. Le propriétaire, c’est la personne appelée quand le taux d’override flambe à 2 heures du matin.

Un processus d’incident qui traite les incidents spécifiques à l’IA comme un incident de sécurité ou de disponibilité serait traité : compte rendu écrit, cause racine, contrôles mis à jour, leçons capturées. Sans cela, la même classe d’incident revient chaque trimestre.

Un rythme de revue qualité, mensuel ou trimestriel selon le volume, où un échantillon de sorties est revu par des experts métier. Cela rattrape la dérive lente que le monitoring seul ne voit pas, surtout pour les sorties génératives où « faux » est un jugement.

Le dernier ensemble de filtres concerne les personnes qui vont réellement utiliser ce que l’IA produit. Trois vérifications décident généralement si le lancement est ressenti comme une amélioration ou comme une charge supplémentaire.

Les utilisateurs de terrain ont-ils été formés aux limites du système, pas seulement à ses fonctionnalités ? « Il peut halluciner » est un fait qu’ils doivent intérioriser avant d’accepter ses sorties comme des brouillons à éditer plutôt que comme des réponses à transmettre.

Existe-t-il une manière simple de signaler une sortie fausse, dans le workflow lui-même, en moins de clics que le contournement n’en demanderait ? Sans cela, l’équipe apprend à corriger silencieusement les erreurs et l’organisation ne les voit jamais.

Et le modèle de support est-il clair ? Quand un utilisateur n’est pas sûr de pouvoir faire confiance à une sortie, à qui demande-t-il, et à quelle vitesse obtient-il une réponse qui lui permet de continuer à travailler ? Un déploiement IA sans modèle de support dès le premier jour est un déploiement où les utilisateurs font trop confiance à la sortie, ne lui font pas assez confiance, ou cessent de l’utiliser tout court.

L’intérêt d’une checklist de préparation n’est pas de ralentir l’IA. C’est de faire la différence entre un déploiement qui survit à son premier incident et un déploiement qui se fait silencieusement retirer six semaines plus tard, sans que l’organisation soit plus avancée sur les raisons. La gouvernance définit ce que l’organisation est prête à accepter. La checklist de préparation, c’est ce qui prouve qu’elle est opérationnellement capable de le délivrer.

Le contexte plus large, dont la manière dont les filtres de préparation s’insèrent dans une vraie feuille de route IA et un vrai modèle opératoire, est rassemblé dans le cluster stratégie IA et automatisation. Et lorsque la question passe de « avons-nous une checklist » à « nous en avons une et il nous faut quelqu’un pour la faire tourner réellement sur plusieurs déploiements sans ralentir le métier », c’est exactement ce sur quoi mon accompagnement gestion de projet et stratégie digitale est construit.