Lancer un projet IA : du pilote à la production

Un pilote d'intelligence artificielle qui impressionne en démonstration n'est pas un produit. Entre les deux se trouve un passage que beaucoup d'entreprises n'ont jamais franchi : celui de la production, avec ses utilisateurs réels, ses droits d'accès, ses coûts récurrents et ses obligations. Cet article décrit ce passage et les conditions pour le réussir.

Le pilote qui s'éternise

• Données extraites à la main, sans propriétaire
• Droits flous, accès temporaires jamais retirés
• Coûts non suivis
• Utilité jamais mesurée côté métier
• Utilisateurs non formés

Le passage en production

• Plateforme de données gouvernée
• Environnements séparés et traçabilité
• Évaluation continue des réponses
• Utilité mesurée avec les utilisateurs
• Coûts suivis, critères d'arrêt connus

Le modèle est rarement ce qui bloque. Ce sont les données, les droits et l'exploitation.

Pourquoi tant de pilotes restent des pilotes

Les raisons se répètent d'un secteur à l'autre.

Les données du pilote ne sont pas celles de la production. Le pilote a fonctionné sur un extrait propre, préparé à la main par une équipe motivée. En production, les données arrivent en continu, avec des trous, des doublons et des formats qui changent quand un système amont est mis à jour.

Les droits n'ont pas été traités. Pendant le pilote, tout le monde avait accès à tout. En production, un assistant qui répond à un opérateur d'atelier n'a pas à lui montrer les contrats fournisseurs ni les salaires du bureau d'études. Reconstruire ces droits après coup est long et coûteux.

Les coûts n'ont pas été mesurés. Un pilote avec dix utilisateurs consomme peu. Un déploiement à l'échelle de l'entreprise, avec des requêtes longues sur des modèles de langage (LLM), change d'ordre de grandeur. Sans suivi, la facture surprend.

L'adoption a été supposée. Le pilote a été testé par ses concepteurs. Les utilisateurs cibles, eux, ont un métier à faire et n'adopteront l'outil que s'il leur fait gagner du temps dès la première semaine.

Ces quatre causes ont un point commun : elles relèvent de la gouvernance, pas de la performance du modèle. C'est précisément pour cela que la gouvernance n'est pas un frein. Elle est ce qui permet de dire oui à la production.

Les conditions du passage en production

Une plateforme de données gouvernée

Le pilote peut vivre sur un poste de travail. La production a besoin d'une plateforme : un entrepôt de données où les sources sont intégrées, documentées et contrôlées, où les transformations sont versionnées, testées et exécutées automatiquement. Lorsqu'un assistant de maintenance cite une durée d'intervention, on sait de quelle table elle vient et quand elle a été rafraîchie.

Des environnements séparés

Développement, recette, production. Cette séparation classique du logiciel s'applique à l'IA. On teste un nouveau modèle, une nouvelle consigne ou une nouvelle version de la base documentaire en recette, avec des jeux de données représentatifs, avant de l'exposer aux utilisateurs. Cela évite le scénario où une mise à jour de modèle chez l'éditeur, qu'il s'agisse de Claude, de GPT ou de Mistral, change le comportement du système un lundi matin sans que personne ne l'ait anticipé.

Une traçabilité complète

Chaque réponse produite doit pouvoir être reconstituée : quelle question, quel utilisateur, quels documents ou données, quel modèle et quelle version, quelle réponse. Ce journal permet d'enquêter sur un incident, alimente l'évaluation continue et constitue la documentation exigée par l'AI Act européen pour les systèmes soumis à des obligations de transparence ou classés à haut risque.

Si des données personnelles transitent, le journal lui-même est un traitement au sens du Règlement général sur la protection des données (RGPD) : durée de conservation limitée, accès restreint, finalité définie. Le délégué à la protection des données (DPO) doit le valider.

Une évaluation continue

Un modèle ne se dégrade pas seul, mais son environnement change : nouveaux équipements, nouvelles procédures, nouveau vocabulaire. Il faut un jeu de questions de référence, construit avec le métier, rejoué régulièrement, avec des seuils d'alerte. Une réponse juste en janvier peut devenir fausse en juin parce qu'une procédure a été révisée.

Phase 1Pilote cadré

• Un cas d'usage, des utilisateurs identifiés
• Données gouvernées dès le pilote
• Critères de succès et d'arrêt écrits

Phase 2Industrialisation

• Environnements séparés, déploiement répétable
• Droits appliqués dans la plateforme
• Journalisation et évaluation continue

Phase 3Exploitation

• Formation et retour des utilisateurs
• Coûts suivis chaque mois
• Revue régulière : étendre, corriger ou arrêter

Mesurer l'utilité côté métier

La qualité technique d'un système ne dit pas s'il est utile. L'utilité se mesure là où le travail se fait. Quelques indicateurs qui parlent aux directions métiers :

• Le temps entre une question et une action réalisée, par exemple entre le signalement d'une panne et le lancement de la bonne procédure.
• La part des réponses signalées comme incorrectes par les utilisateurs eux-mêmes.
• La part des utilisateurs cibles qui reviennent la semaine suivante.

Ces mesures sont définies avant le déploiement et suivies par le responsable métier, pas seulement par l'équipe technique.

Former les utilisateurs et organiser le retour

Un assistant IA ne se déploie pas comme une mise à jour de messagerie. Les utilisateurs doivent comprendre ce qu'il fait, ce qu'il ne fait pas et comment lire une réponse avec ses sources.

Dans un atelier ou un centre de maintenance, cela passe par des sessions courtes, sur des cas réels, animées avec un référent métier. On y montre les limites autant que les capacités : l'outil peut se tromper, la source citée fait foi, une procédure de sécurité ne se contourne jamais sur la base d'une réponse générée.

Prévoyez un canal de remontée simple. Un bouton « cette réponse est fausse » directement dans l'interface vaut mieux qu'une adresse électronique que personne n'utilisera.

Exploitation et maîtrise des coûts

Une fois en production, le système a besoin d'une équipe d'exploitation, même réduite, et d'un suivi des coûts. La démarche FinOps, qui consiste à piloter les dépenses d'informatique en nuage comme un poste financier, s'applique aux projets IA avec quelques spécificités.

• Les appels aux modèles sont facturés à l'usage. Il faut suivre la consommation par cas d'usage et par équipe, et fixer des plafonds.
• Le choix du modèle a un impact direct : un modèle plus petit suffit souvent pour classer ou extraire, un modèle plus grand est réservé aux tâches complexes.
• Les coûts humains ne disparaissent pas : maintenance de la base documentaire, revue des signalements, mises à jour réglementaires.

Un tableau de bord mensuel mettant en regard le coût et les indicateurs d'utilité est le meilleur outil de dialogue entre la DSI, la direction financière et le métier.

Savoir quand arrêter

Le passage en production n'est pas irréversible. Trois situations justifient un arrêt ou un retour en recette :

• L'utilité mesurée reste inférieure au seuil fixé au cadrage après une période raisonnable d'usage.
• Un incident de conformité ou de sécurité survient : fuite de document, réponse dangereuse sur un équipement critique, traitement de données personnelles non prévu.
• Le contexte réglementaire ou contractuel change, par exemple la requalification du système dans une catégorie de risque plus élevée au sens de l'AI Act.

Arrêter un projet qui ne tient pas ses promesses n'est pas un échec. C'est la preuve que les critères ont été posés et respectés.

À retenir

• Les pilotes échouent sur les données, les droits, les coûts et l'adoption, rarement sur le modèle.
• La production exige une plateforme gouvernée, des environnements séparés et une traçabilité complète.
• L'évaluation continue doit être construite avec le métier et rejouée régulièrement.
• L'utilité se mesure sur le terrain, pas dans un rapport technique.
• Les coûts se pilotent par cas d'usage, avec des plafonds et un tableau de bord partagé.
• Les critères d'arrêt fixés au cadrage s'appliquent aussi en production.

Checklist

• Les données de production sont intégrées sur une plateforme gouvernée, avec transformations testées et documentées.
• Les droits d'accès aux documents et aux données sont appliqués dans le système, pas seulement décrits.
• Chaque réponse est journalisée avec ses sources, son modèle et sa version, dans un cadre validé par le DPO.
• Un jeu d'évaluation métier existe et est rejoué à chaque changement.
• Les utilisateurs sont formés et disposent d'un canal de signalement dans l'interface.
• Les coûts sont suivis par cas d'usage avec des plafonds d'alerte.