Du diagnostic à la production maîtrisée

Ce qu'on voit parfois

Chaque direction arrive avec sa liste d'idées d'IA, et le comité arbitre sur celle qui est défendue le plus fort. On démarre par l'outil (« il nous faut un chatbot ») plutôt que par le problème, et l'on découvre trop tard que les données n'existent pas ou qu'une simple règle aurait suffi.

Comment le faire correctement

1. Un guichet unique, une grille commune pour toutes les directions : on compare des projets, pas des orateurs.
2. Partir des irritants métier, pas des solutions : combien de temps ou d'argent perd-on aujourd'hui, et que coûte une erreur ?
3. Filtrer avant d'évaluer : est-ce vraiment un problème d'IA ? Une règle, un meilleur classement des documents ou un logiciel standard suffit souvent. C'est l'étape qui fait gagner le plus de temps. Et si l'IA est justifiée, commencer par la solution la plus simple : un outil existant, puis un prompt, puis un RAG, l'entraînement spécifique (fine-tuning) en dernier recours.
4. Évaluer sur quatre axes, avec chaque direction : la valeur (mesurable) ; la faisabilité, et d'abord les données (existent-elles, sont-elles accessibles, à jour, personnelles ?) et les exigences du métier (volume, latence acceptable, explicabilité) ; le risque (coût d'une mauvaise réponse, équité des décisions, contraintes RGPD et AI Act) ; le coût total, fonctionnement compris.
5. Prioriser : quelques gains rapides et un ou deux paris structurants, chacun avec un sponsor métier.
6. Annoncer un « non » sans surprise : la direction a participé à la notation, et repart avec une condition de réouverture claire.

Checklist

• grille commune à toutes les directions
• irritant chiffré
• filtre « est-ce de l'IA ? » passé
• données identifiées et accessibles
• coût d'une erreur qualifié
• risque réglementaire qualifié
• coût de fonctionnement estimé
• sponsor nommé

Ce qu'on voit parfois

Un POC réussi en démonstration, puis des mois pour le « passer en production » sans critère d'arrêt. Personne n'a mesuré la situation de départ : impossible de dire, six mois plus tard, si le projet a apporté quelque chose.

Comment le faire correctement

1. Distinguer POC et MVP. La preuve de concept (POC) prouve que c'est faisable, vite et pour peu cher : elle décide de l'entrée dans le portefeuille. Le produit minimum viable (MVP) prouve que c'est utilisé : il décide du passage à l'échelle.
2. Fixer le go/no-go avant le test : un plancher (ce qui doit absolument marcher) et des critères de succès, écrits avant d'avoir vu les résultats.
3. Mesurer l'indicateur de départ avant de lancer, avec une méthode (par exemple un échantillon de recherches chronométrées), et fixer une cible avec le métier.
4. Livrer par lots courts et déployables, les garde-fous avant les fonctionnalités.
5. Suivre deux indicateurs de contrôle en plus de la valeur : l'adoption et la qualité des réponses.
6. S'autoriser à arrêter : une revue régulière où l'arrêt est une option réelle.

Checklist

• POC court et peu coûteux
• go/no-go écrit avant le test
• indicateur de départ mesuré
• cible fixée avec le métier
• lots courts, garde-fous d'abord
• adoption et qualité suivies
• revue avec droit d'arrêt

Ce qu'on voit parfois

Un assistant branché sur un dossier de documents, testé « à l'œil » sur trois questions, avec un modèle choisi d'après sa réputation. Il répond toujours, même quand l'information n'existe pas. Personne ne sait dire s'il s'est amélioré ou dégradé après une mise à jour.

Comment le faire correctement

1. Vérifier que c'est un problème de RAG : répondre à des questions à partir d'un corpus précis, avec une source vérifiable. Si une recherche classique suffit, pas besoin d'IA.
2. Qualifier le corpus avant tout : qui le maintient, quelle version fait foi, contient-il des données personnelles, et quelle est sa qualité (complétude, exactitude, actualité, cohérence) ? Un document obsolète ou un renvoi vers un article inexistant produira une réponse fausse, mais bien formulée.
3. Découper selon la structure des documents (articles, sections) plutôt qu'en blocs de taille fixe, en gardant les références (document, version, article) : c'est ce qui permet de citer.
4. Mesurer la recherche séparément de la réponse. Si le bon passage n'est pas retrouvé, le meilleur modèle ne peut pas répondre juste. Changer de modèle d'embeddings impose de réindexer tout le corpus.
5. Contraindre la réponse : uniquement à partir des extraits, avec la source citée, et un refus quand l'information manque, testé avec des questions hors corpus.
6. Évaluer avant de livrer sur un jeu de questions validé par le métier, avec des seuils fixés avant le test (voir « Évaluer un LLM »).
7. Sécuriser et borner : clés côté serveur, quotas et plafonds, information des utilisateurs sur l'envoi de leurs données.
8. Réévaluer à chaque changement de modèle, de prompt ou de documents : un RAG peut régresser sans que personne ne le voie.

Checklist

• corpus qualifié et versionné
• découpage par structure
• recherche mesurée seule
• citations obligatoires
• refus testé hors corpus
• seuils fixés avant le test
• coûts bornés
• réévaluation à chaque changement

Ce qu'on voit parfois

Un agent à qui l'on donne des outils puissants et des consignes dans le prompt : « ne valide jamais un dossier suspect ». Le jour où un document contient une instruction cachée, ou où le modèle se trompe, rien ne l'empêche d'agir.

Comment le faire correctement

1. L'IA propose, le code tranche. Les décisions qui engagent (statut, montant, routage) sont prises ou vérifiées par du code déterministe, pas par le modèle.
2. Un prompt demande, un schéma empêche. Ce qui ne doit pas arriver ne figure pas dans les outils de l'agent : une action absente de son schéma est impossible, quel que soit le prompt.
3. Traiter tout contenu externe comme une donnée, jamais comme une instruction : une injection de consignes (prompt injection) arrive par le document, pas par l'utilisateur.
4. Recalculer côté serveur tout ce que l'agent produit et qui a une conséquence (montants, seuils, statuts incohérents).
5. Un humain valide les décisions qui touchent une personne, avec un motif obligatoire en cas de rejet.
6. Contrôler le quota avant tout appel externe : sinon on paie et on transmet des données pour un résultat inutilisé.
7. Tester les attaques, pas seulement le parcours nominal : injections, documents incohérents, entrées hors format.

Checklist

• décisions engageantes dans le code
• actions interdites absentes du schéma
• contenus externes traités comme données
• valeurs recalculées côté serveur
• validation humaine tracée
• quota vérifié avant l'appel
• test d'injection réalisé

Ce qu'on voit parfois

« On a testé, ça marche. » Quelques questions choisies par l'équipe, un score moyen flatteur, et un seuil décidé après avoir vu les résultats. Le jour où une réponse invente une condition contractuelle, personne ne comprend comment les tests ont pu passer.

Comment le faire correctement

1. Un jeu de questions de référence (golden set) validé par le métier, représentatif des vraies questions, cas pièges et hors périmètre compris.
2. Des seuils fixés avant le test, jamais après.
3. Des critères bloquants, pas seulement une moyenne. Une réponse qui invente une garantie et une réponse maladroite pèsent pareil dans un score moyen : un seul échec sur un critère bloquant (affirmation absente des sources, source fausse, absence de refus) doit bloquer la version.
4. Vérifier par le code ce qui peut l'être (citation attendue, format) : c'est gratuit et reproductible.
5. Confier au LLM juge seulement ce que le code ne sait pas vérifier, comme la fidélité aux sources. Le juge est lui-même un LLM, avec des biais connus (préférence pour les réponses longues, ou pour celles de son propre modèle).
6. Calibrer le juge avant de s'y fier : le comparer à une notation humaine à l'aveugle, lui soumettre des réponses volontairement fausses, fixer avant le test le nombre de pièges à détecter et de désaccords tolérés. Choisir un juge d'un autre fournisseur que le modèle évalué.
7. Figer la référence avant de changer d'outil : mesurer l'ancien système avant de le retirer, pour pouvoir dire « c'est mieux », pas seulement « ça marche ».
8. Réévaluer à chaque changement de modèle, de prompt ou de documents.

Checklist

• golden set validé par le métier
• seuils écrits avant le test
• critères bloquants définis
• échecs lus un par un
• contrôles par le code d'abord
• juge calibré contre une notation humaine
• juge d'un autre fournisseur
• référence figée avant tout changement

Ce qu'on voit parfois

Le modèle « le plus puissant du marché » par défaut, une facture découverte en fin de mois, et des quotas réglés sur la consommation moyenne. Puis un jour, le fournisseur retire le modèle, et l'application tombe.

Comment le faire correctement

1. Chiffrer avant de choisir : coût par question, volume attendu, ordre de grandeur mensuel, à valider avec le métier.
2. Définir la qualité sur vos questions, pas sur un classement du marché, puis retenir le modèle le moins cher qui passe le seuil. Si une exigence (par exemple la citation exacte) est critique, elle fait partie du seuil, et on la paie.
3. Borner les coûts sur trois étages : par conception (n'appeler le modèle que si c'est utile, plafonner la longueur des réponses) ; par des quotas calculés sur le pire cas, pas sur la moyenne ; par un plafond de dépense chez le fournisseur, dédié au projet.
4. Isoler chaque projet (espace de travail et clé dédiés) pour lire son coût réel et limiter les dégâts d'une clé compromise.
5. Suivre le cycle de vie des modèles : les fournisseurs les retirent à date fixe. Une migration se teste sur le parcours le plus exigeant, pas seulement sur le nominal.
6. Garder la réversibilité : une architecture qui permet de comparer un autre fournisseur sur le même jeu de questions.

Checklist

• coût chiffré avant le choix
• seuil de qualité défini sur vos questions
• moins cher qui passe le seuil
• quotas sur le pire cas
• plafond de dépense dédié
• coût lu par projet
• dates de retrait suivies
• comparaison avec un second fournisseur

Ce qu'on voit parfois

Des données clients envoyées telles quelles à un fournisseur de modèle, sans savoir combien de temps il les conserve ni s'il s'en sert pour entraîner ses modèles. Le DPO découvre le projet une semaine avant la mise en production.

Comment le faire correctement

1. Impliquer le DPO et le RSSI dès le cadrage, pas à la fin : analyse d'impact (AIPD) et classement au regard de l'AI Act avant le premier lot.
2. N'envoyer que le nécessaire (minimisation), pseudonymisé quand c'est possible.
3. Informer les personnes qu'une IA intervient, et de ce qui est envoyé, avant l'envoi.
4. Lire les conditions du fournisseur : durée de conservation, usage pour l'entraînement (à refuser), accord de traitement des données ; négocier une conservation nulle quand l'enjeu le justifie.
5. Savoir où l'inférence est exécutée : un endpoint européen n'est pas une garantie que toutes les données restent en Europe ; il faut lire ce que le fournisseur s'engage à faire.
6. Clarifier la responsabilité partagée avec le fournisseur : ce qu'il garantit, et ce qui reste à votre charge.
7. Clés côté serveur, accès par rôle, journaux sans contenu sensible, et une décision qui touche une personne toujours signée par un humain.

Checklist

• DPO et RSSI dès le cadrage
• AIPD et classement AI Act
• minimisation
• information avant envoi
• conservation et entraînement vérifiés
• accord de traitement
• lieu d'inférence vérifié
• journaux sans contenu sensible

Ce qu'on voit parfois

L'équipe projet présente ses propres résultats, la ligne risque ne peut que les lire, et la signature se fait sur la confiance. Le dossier dit ce qui marche, rarement ce qui ne marche pas.

Comment le faire correctement

1. Clarifier qui signe selon la gouvernance de l'organisation : en général le propriétaire métier, après l'avis des fonctions risque, conformité, sécurité et DPO.
2. Rencontrer la ligne risque au début, pour savoir ce qu'un dossier doit contenir, plutôt que de le découvrir au moment de signer.
3. Un dossier fait pour être challengé : usage prévu et interdit, données envoyées et à qui, protocole d'évaluation avec seuils fixés avant, tous les résultats, y compris les mauvais, limites connues, garde-fous, plan de surveillance.
4. Tout rendre rejouable : jeu de questions, grille de notation et scripts, pour que la ligne risque refasse les tests elle-même. Une validation qui ne peut que lire n'est pas indépendante.
5. Un cadre commun pour toutes les applications, testé d'abord sur un pilote, plutôt qu'un dossier différent par projet.

Checklist

• signataire clarifié
• ligne risque rencontrée au début
• usage interdit écrit
• seuils fixés avant
• résultats complets, mauvais compris
• tests rejouables
• limites et garde-fous documentés
• plan de surveillance

Ce qu'on voit parfois

Un changement poussé directement en production « parce que c'est petit », un bilan « tous les tests passent » accepté sans vérification, et une confiance aveugle dans le bouton « retour arrière ».

Comment le faire correctement

1. Prouver sur une copie de la production : chaque demande de fusion crée une préversion, testée par une personne sur le vrai parcours. Une absence (un fichier qui ne devrait pas être public) ne se voit pas en relisant le code, seulement en testant.
2. Rendre voulues et listées les différences entre environnements (quotas, clés, services) : une différence non voulue fait partir en production une fonction jamais testée.
3. Ne croire aucun bilan sur parole, qu'il vienne d'un développeur ou d'un agent de code : exiger la sortie brute des tests, étape par étape.
4. Faire tourner les tests automatiquement (intégration continue) et rendre leur statut bloquant pour la fusion.
5. Vérifier en production après la fusion : un déploiement réussi ne prouve pas que le parcours fonctionne.
6. Savoir ce qu'un retour arrière ne défait pas : une donnée déjà exposée, un secret déjà fuité, une base déjà migrée.

Checklist

• préversion par demande de fusion
• test humain du parcours
• différences d'environnement listées
• sortie brute des tests exigée
• intégration continue bloquante
• vérification en production
• limites du retour arrière connues

Ce qu'on voit parfois

Les pannes sont signalées par les utilisateurs, la qualité des réponses n'est plus mesurée une fois en production, et chaque incident se termine par « c'est réparé » sans que rien n'empêche qu'il revienne.

Comment le faire correctement

1. Détecter avant l'utilisateur : une sonde qui rejoue le parcours principal à intervalle régulier, des alertes sur les erreurs serveur et sur la dépense ; surveiller latence, trafic, saturation et erreurs, et fixer des objectifs de service (SLO) sur ceux qui comptent pour l'utilisateur. Sans cela, la durée d'une panne est le temps jusqu'à ce que quelqu'un la remarque.
2. Se méfier de ce qui ne casse rien : une exposition de données ou une faille d'autorisation ne déclenche aucune alerte, et dure aussi longtemps que personne ne la cherche.
3. Contenir : mesurer l'impact (qui, quelles données), revenir à la version précédente, informer les personnes touchées et le sponsor (ce qu'on sait, ce qu'on fait, quand on refait le point).
4. Corriger à froid : la cause racine se cherche dans les journaux une fois la production stabilisée.
5. Apprendre sans chercher de coupable : distinguer la cause immédiate de la cause racine, et produire une règle ou un outil.
6. Prévoir la reprise : sauvegardes testées et plan de reprise, pas seulement écrits ; veille réglementaire et de sécurité.
7. Surveiller aussi la qualité des réponses : un bouton de signalement dont chaque cas confirmé rejoint le jeu de test, et un échantillon de réponses de production tiré au hasard et noté avec la même grille, car les signalements n'attrapent que les erreurs que quelqu'un remarque. Conserver des réponses réelles est un arbitrage à faire avec le DPO.

Checklist

• sonde sur le parcours principal
• alertes erreurs et dépense
• procédure de contention et de communication
• post-mortem sans coupable
• règle issue de chaque incident
• signalement relié au jeu de test
• échantillon de production noté
• conservation arbitrée avec le DPO

Ce qu'on voit parfois

Un outil livré qui fonctionne, une formation d'une heure, une newsletter, et trois mois plus tard presque personne ne l'utilise. L'adoption a été pensée après la livraison.

Comment le faire correctement

1. Partir de la mission, pas de l'outil : l'IA répond à un irritant que les équipes reconnaissent.
2. Associer les futurs utilisateurs dès le cadrage, et pas seulement à la recette.
3. Mesurer l'usage et la qualité perçue, à côté de la valeur : une adoption faible est un signal à comprendre, pas à cacher.
4. Lever les freins concrets : confiance dans les réponses (sources visibles), place de l'outil dans le parcours de travail, règles claires sur ce qu'on peut y mettre.
5. Un sponsor visible et des relais dans les équipes.

Checklist

• irritant reconnu par les équipes
• utilisateurs associés dès le cadrage
• usage mesuré
• freins identifiés
• sponsor et relais nommés