C’est exactement l’erreur. Un POC réussi ne prouve rien d’autre que la faisabilité technique — la partie qui, aujourd’hui, échoue rarement. Ce qui échoue, c’est la mise en production, l’adoption et le modèle économique.

Voici les quatre questions que je pose avant d’engager quoi que ce soit.

1. Quelle décision ou quel geste métier change ?

Pas « quel outil on déploie » : qu’est-ce que quelqu’un fera différemment lundi matin.

Si la réponse est floue — « gagner du temps », « améliorer la qualité » — le projet n’a pas de cible et ne pourra pas être évalué. Si la réponse est nette — « l’assistante commerciale ne ressaisit plus les bons de commande reçus par mail » — on a un périmètre, un utilisateur, et un avant/après mesurable.

Formulation utile : aujourd’hui X fait Y en Z minutes ; demain X fait Y en Z’ minutes, ou ne le fait plus du tout.

2. Qu’est-ce qui se passe quand le modèle se trompe ?

Toute IA générative produit des sorties fausses avec assurance. La question n’est donc jamais « est-ce que ça peut se tromper » mais combien coûte une erreur, et qui la rattrape.

Trois catégories, dans l’ordre de difficulté croissante :

• Erreur visible et sans conséquence — un brouillon de mail mal tourné, un résumé approximatif. L’utilisateur corrige, le coût est nul. C’est là qu’il faut commencer.
• Erreur visible et coûteuse — un montant erroné dans une commande. Il faut un contrôle humain explicite dans le circuit, ce qui rogne le gain de temps annoncé. À chiffrer honnêtement.
• Erreur invisible — une donnée fausse injectée dans un système aval, une classification silencieusement biaisée. À éviter tant qu’on n’a pas de mécanisme de détection. C’est là que se logent les vrais incidents.

Si un projet tombe dans la troisième catégorie et que personne ne sait comment détecter la dérive, ce n’est pas un projet : c’est une dette en construction.

3. Où sont les données, et qui a le droit de les voir ?

Deux sujets distincts qu’on confond souvent.

La localisation : quelles données sortent du SI, vers quel hébergement, sous quel contrat, avec quelle durée de conservation et quel usage pour l’entraînement. Un engagement de non-entraînement sur les données client doit être écrit dans le contrat, pas déduit d’une page marketing.

Les habilitations : c’est le piège le plus fréquent. Un assistant branché sur une base documentaire hérite des droits du connecteur, pas de ceux de l’utilisateur. Résultat classique : n’importe qui interroge l’assistant et obtient le contenu de dossiers auxquels il n’a pas accès. Le RAG ne crée pas la fuite, il la rend interrogeable en langage naturel — et donc découvrable par accident.

Avant tout déploiement : vérifier que la recherche respecte les ACL à l’exécution, utilisateur par utilisateur. Si l’éditeur ne peut pas le démontrer, la réponse est non.

4. Combien ça coûte en régime établi ?

Le coût d’un pilote n’a aucune valeur prédictive. Ce qu’il faut estimer :

La ligne « maintien » est celle qui surprend le plus. Contrairement à un applicatif classique qui peut rester stable des années, une brique IA vieillit vite : les modèles changent, les API évoluent, les comportements dérivent. Il faut budgéter un entretien récurrent, pas un investissement one-shot.

Et la technique ?

Elle arrive après — et c’est volontaire. Le choix entre un éditeur intégré, une API, un modèle auto-hébergé ou une architecture RAG maison est une conséquence des quatre réponses précédentes, pas un point de départ.

Un projet dont l’erreur est sans conséquence, sur des données non sensibles, avec un volume faible ? Un outil du marché suffit, on n’a rien à construire. Un projet sur des données réglementées, avec des habilitations fines et un volume élevé ? Là seulement la question de l’auto-hébergement devient pertinente — et le coût du choix précédent devient calculable.

Commencer par la technique, c’est choisir une solution avant de connaître le problème. C’est aussi comme ça qu’on se retrouve avec un cluster GPU qui sert à résumer des comptes rendus de réunion.