80% des POC IA ne passent jamais en production. Ce n'est pas un problème de technologie. Le POC fonctionnait. C'est un problème de gouvernance non anticipée, de sécurité bâclée et de formation inexistante. Cette semaine a un objectif unique : franchir la ligne.

Pourquoi les POC meurent en semaine 4

Les trois causes de décès les plus fréquentes :

  • Personne ne sait qui décide. Le modèle sort une réponse fausse. Qui alerte ? Qui corrige ? Qui a autorité pour mettre le système en pause ? Si ces questions n'ont pas de réponse avant la mise en production, la première erreur provoque une crise de gouvernance.
  • La sécurité bloque au dernier moment. Le RSSI découvre le projet deux jours avant la mise en prod et demande une analyse de risque qui prend six semaines. Résultat : le projet meurt dans les limbes.
  • Les utilisateurs ne comprennent pas ce qu'ils ont entre les mains. Sans formation, ils utilisent l'outil de façon sous-optimale, obtiennent de mauvais résultats, concluent que « l'IA ne marche pas » et abandonnent.

La gouvernance minimale — qui fait quoi

Vous n'avez pas besoin d'un comité de gouvernance IA de vingt personnes. Vous avez besoin de trois rôles clairement attribués, même s'ils sont portés par les mêmes personnes :

  • Le décideur. Qui peut décider de modifier les paramètres du modèle, de restreindre son accès ou de le mettre hors ligne ? C'est une personne nommément désignée, pas « l'équipe IT ».
  • Le superviseur métier. Qui surveille la qualité des outputs au quotidien ? Qui remonte les anomalies ? Ce rôle est tenu par un utilisateur expérimenté du domaine métier — pas par un développeur.
  • Le référent alerte. Qui contacte-t-on en cas d'incident ? Comment ? En combien de temps s'attend-on à une réponse ? Ce processus doit exister sur papier avant le premier jour en production.

La checklist sécurité avant mise en production

Cinq points non négociables :

  1. Accord de traitement des données (DPA) signé avec le fournisseur du modèle. Si vous utilisez un cloud américain, ce DPA doit couvrir explicitement le Cloud Act. Si vous ne pouvez pas obtenir ce DPA, changez de fournisseur.
  2. Audit des logs. Chaque requête envoyée au modèle doit être loguée avec l'identité de l'utilisateur, la date et le contenu (ou un hash si le contenu est confidentiel). Ces logs sont votre traçabilité en cas d'incident.
  3. Droits d'accès. Qui peut accéder au système ? La liste est nominative. Aucun compte générique, aucun accès « tout le monde ».
  4. Procédure de mise hors ligne. En combien de temps peut-on couper l'accès si nécessaire ? Cette procédure doit être testée avant la mise en production.
  5. Registre de traitement RGPD mis à jour. Si le système traite des données personnelles, votre registre de traitement doit refléter ce nouveau traitement avant le jour J.

La formation utilisateurs — 1 heure suffit

La formation n'a pas besoin d'être longue. Elle doit couvrir quatre points en 60 minutes :

  • Ce que le système fait et ce qu'il ne fait pas (les limites sont aussi importantes que les capacités)
  • Les cas d'usage validés et ceux qui sont explicitement exclus
  • Comment interpréter les outputs — quand faire confiance, quand vérifier
  • Comment signaler un problème ou une anomalie

Format recommandé : une session de 45 minutes en présentiel ou visio, suivie d'un document de référence d'une page. Pas plus.

Les métriques de suivi J+30

Définissez avant le lancement les indicateurs que vous suivrez à J+30 :

  • Taux d'adoption (% des utilisateurs cibles actifs après 30 jours)
  • Qualité des outputs (taux de validation sans correction par les utilisateurs)
  • Volume d'usage (nombre de requêtes par jour, par utilisateur)
  • Incidents signalés (nombre, nature, délai de résolution)

Ces métriques sont ce qui vous permettra de décider, à J+30, si vous scalez ou si vous pivotez.

La liste des 5 choses à avoir le jour J

  1. DPA signé avec le fournisseur
  2. Gouvernance documentée : décideur, superviseur, référent alerte
  3. Logs activés et accessibles
  4. Utilisateurs formés (session réalisée, document distribué)
  5. Registre de traitement RGPD à jour

Si l'un de ces cinq points n'est pas coché le matin du jour J, reportez le lancement. Un report de 48 heures vaut mieux qu'un incident à J+3 qui tuerait le projet pour de bon.

Bilan semaine 4

  • Gouvernance minimale définie : trois rôles attribués nominalement
  • Checklist sécurité complète : DPA, logs, droits, procédure d'urgence, registre RGPD
  • Formation utilisateurs réalisée
  • Métriques J+30 définies et outils de suivi en place

Vous avez lancé. Dans 30 jours, vous saurez si vous scalez, adaptez ou pivotez. Le billet suivant vous dit comment faire ce bilan et construire votre roadmap IA 12 mois.

Lire le bilan J+30 et comment scaler →