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.
Ce que je ne prends pas
- 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.
Questions fréquentes
Concrètement, à quoi sert l'IA dans mes process ?
À automatiser ce qui vous coûte du temps sur des tâches répétitives et vérifiables : tri et réponse aux emails, extraction de données de documents, recherche dans votre documentation, support de premier niveau. J'intègre l'IA uniquement là où le gain est mesurable.
Mes données partent-elles chez OpenAI ?
Cela dépend de l'architecture retenue, et c'est une décision à prendre avant le développement. Les API professionnelles permettent de s'engager sur la non-utilisation de vos données pour l'entraînement ; pour les données les plus sensibles, un modèle auto-hébergé reste possible. On arbitre selon votre niveau de sensibilité.
Combien coûte l'IA à l'usage ?
Le coût dépend du volume traité et du modèle choisi, et il peut varier d'un facteur dix entre deux modèles pour une qualité comparable sur votre tâche. L'estimation du coût mensuel à votre volume réel fait partie du cadrage — c'est souvent ce qui détermine la faisabilité.
Comment savoir si le système fonctionne bien ?
Avec un jeu de cas de test représentatifs et une mesure du taux de réussite, cas limites inclus. C'est ce qui permet de vérifier qu'un changement de prompt ou de modèle améliore réellement les choses, au lieu de le supposer.
Faut-il remplacer nos outils actuels ?
Non, et c'est rarement une bonne idée. L'automatisation se branche sur ce que vous utilisez déjà, via les API ou des workflows n8n. Remplacer un outil qui fonctionne pour y ajouter de l'IA transforme un petit projet en migration.