Presque toutes les entreprises que nous rencontrons ont déjà « testé l’IA ». Quelqu’un a montré un résultat bluffant en réunion, l’enthousiasme est monté, puis rien. Six mois plus tard, l’outil est utilisé par trois personnes, sans règle commune, et personne ne sait dire s’il fait gagner du temps.
Ce n’est pas un problème de modèle. C’est un problème de cadrage : un test n’est pas un pilote, et un pilote n’est pas un usage.
Pourquoi les démonstrations réussissent toujours
Une démonstration est faite sur un cas choisi, avec des données propres, par quelqu’un qui sait formuler sa demande, et jugée par une personne qui découvre. Ces quatre conditions ne se retrouvent jamais en production.
La bonne question n’est pas « est-ce que ça marche ? », mais « est-ce que ça marche encore quand la donnée est sale, la demande mal formulée et le résultat vérifié par quelqu’un d’exigeant ? ».
Les cinq attaches d’un pilote sérieux
Un pilote qui tient est toujours attaché à cinq points. S’il en manque un, il finit en démonstration prolongée.
1. Une tâche, pas une technologie
« Utiliser l’IA » n’est pas un projet. « Réduire de moitié le temps de préparation d’une proposition commerciale » en est un. La tâche doit être nommée, fréquente, et déjà réalisée aujourd’hui par quelqu’un : c’est ce qui donne un point de comparaison.
2. Une donnée explicitement autorisée
Quelles sources le système a-t-il le droit de lire ? Qui l’a décidé ? Les données clients peuvent-elles sortir de l’entreprise ? Tant que ces réponses ne sont pas écrites, le pilote avance sur un terrain juridique instable, et personne n’osera l’étendre.
3. Une validation humaine placée au bon endroit
Le contrôle humain ne doit pas être partout : il doit être là où une erreur engage l’entreprise. Un résumé de réunion peut être relu distraitement. Un devis, un contrat, un message envoyé à un client ne peuvent pas partir sans relecture. Placer ce point de validation est une décision de conception, pas un détail d’interface.
4. Un indicateur métier observable
Pas « la qualité des réponses », trop vague, mais des grandeurs que l’on peut relever chaque semaine : temps moyen par dossier, taux de reprise après relecture, nombre de dossiers traités, nombre d’erreurs détectées en aval. Un indicateur que personne ne relève n’existe pas.
5. Un coût connu à l’avance
Le coût par appel au modèle, multiplié par le volume réel, donne un budget mensuel. Beaucoup de pilotes fonctionnent parfaitement et se révèlent économiquement absurdes à l’échelle. Autant le savoir avant.
Les questions à poser avant tout pilote
- Quelle tâche précise, réalisée combien de fois par mois ?
- Quelles données, autorisées par qui, et jusqu’où ?
- Qui valide, à quel moment, et sur quel critère ?
- Quel indicateur relèvera-t-on, et à quelle fréquence ?
- Quel coût mensuel au volume réellement attendu ?
Mesurer la qualité avant d’élargir
La méthode la plus simple reste la meilleure : constituer un jeu de trente à cinquante cas réels, représentatifs, y compris les cas pénibles, et faire évaluer les résultats par la personne qui fait le travail aujourd’hui. Deux notes suffisent : utilisable tel quel, ou non.
Cette évaluation prend une demi-journée et vaut mieux que trois mois de débats. Elle donne aussi une base : quand on changera de modèle ou de formulation, on saura si l’on progresse ou si l’on régresse.
Ce que change la confidentialité
La confidentialité n’est pas un frein à ajouter à la fin : elle détermine l’architecture. Selon la sensibilité des données, on choisira un service en ligne avec un contrat adapté, un hébergement européen, ou un modèle exécuté dans votre infrastructure. Ces trois options n’ont ni le même coût, ni le même niveau de performance : arbitrer tôt évite de tout reconstruire.
Dans tous les cas, quelques règles simples suffisent à éviter l’essentiel des incidents : ne jamais confier de données personnelles ou contractuelles sans base juridique claire, journaliser ce qui a été envoyé, et former les équipes à reconnaître ce qui ne doit pas sortir.
Passer à l’échelle, ou arrêter
À la fin d’un pilote, trois issues sont acceptables : étendre, ajuster, ou arrêter. La quatrième, laisser vivre sans décider, est celle qui coûte le plus cher, parce qu’elle installe des usages non encadrés.
Arrêter un pilote n’est pas un échec. C’est le résultat normal d’une expérimentation sur deux ou trois sujets : l’objectif était d’apprendre vite et pour peu cher, et c’est exactement ce qui s’est produit.
À retenir
- Partez d’une tâche fréquente et déjà réalisée : elle fournit le point de comparaison.
- Écrivez les données autorisées avant d’écrire le premier prompt.
- Placez la validation humaine là où une erreur engage l’entreprise, pas partout.
- Évaluez sur trente à cinquante cas réels, y compris les cas difficiles.
- Décidez explicitement à la fin : étendre, ajuster ou arrêter.