L'IA n'a d'intérêt que là où elle remplace un travail réel
La plupart des projets d'IA en entreprise échouent pour la même raison : ils partent de la technologie et cherchent ensuite un usage. La démarche inverse fonctionne mieux. On identifie d'abord une tâche qui consomme réellement du temps, qui se répète, et dont le résultat se vérifie facilement, puis on regarde si l'IA sait la faire.
Ce filtre élimine beaucoup de projets, et c'est son intérêt. Il en reste toujours quelques-uns dont le gain est net et mesurable : c'est par ceux-là qu'on commence.
Les cas d'usage qui tiennent en production
Quatre familles reviennent le plus souvent, et donnent des résultats fiables :
- Traitement de documents : extraire des données structurées de factures, contrats, formulaires ou emails, et les déposer dans votre outil métier.
- Recherche dans la documentation interne, un assistant qui répond en citant vos propres documents (RAG), plutôt qu'un moteur de recherche par mots-clés.
- Support client de premier niveau : traiter les demandes répétitives, et surtout savoir passer la main à un humain au bon moment.
- Workflows d'automatisation : chaîner vos outils entre eux (n8n, API) avec une étape d'IA là où une règle fixe ne suffit pas.
Mesurer avant de généraliser
Un système d'IA ne se valide pas à l'œil sur trois exemples réussis. Il faut un jeu de cas de test représentatifs, y compris les cas tordus, et une mesure de ce qui passe et de ce qui échoue, c'est ce qu'on appelle des évaluations. Sans elles, on ne sait pas si un changement de prompt ou de modèle améliore les choses ou les dégrade.
Cela vaut aussi pour le retour sur investissement. Le temps gagné se mesure sur la tâche visée, avant et après, sur une période définie. Un gain annoncé sans périmètre ni fenêtre de mesure ne vaut rien : ni pour vous, ni pour moi.
Vos données, et où elles vont
Brancher un modèle d'IA sur vos données soulève des questions qu'il vaut mieux régler avant le développement : quelles données sortent de votre système, chez quel fournisseur, dans quelle région, avec quelle durée de conservation, et sont-elles utilisées pour entraîner le modèle.
Selon la sensibilité, les réponses diffèrent : une API cloud avec engagement de non-entraînement suffit souvent, un modèle auto-hébergé s'impose parfois. Ce choix est arbitré au cadrage, avec la conformité RGPD, pas découvert après la mise en service.
Quand une autre solution sera plus adaptée
- Les projets d'IA sans cas d'usage identifié. « Mettre de l'IA » n'est pas un objectif. Sans tâche précise et mesurable, je préfère ne pas démarrer.
- L'automatisation de process qui ne sont pas stabilisés. Automatiser un process qui change tous les mois revient à reconstruire tous les mois. On stabilise d'abord.
- L'entraînement de modèles de zéro. Je travaille avec des modèles existants et leur adaptation ; l'entraînement de modèles fondamentaux n'est pas mon métier.
- Les gains chiffrés promis avant mesure. Je ne m'engage pas sur un pourcentage de temps gagné avant d'avoir mesuré sur vos données réelles.
