Commencer par un problème, pas par l'IA
La question « que pourrait faire l'IA pour nous ? » paraît naturelle. Elle mène pourtant rarement à un résultat, car elle part d'une technologie et cherche où l'appliquer. La question utile est plus simple : quel travail prend trop de temps, produit trop d'erreurs ou arrive trop tard, aujourd'hui, dans votre entreprise ? L'IA n'est qu'une des réponses possibles.
Selon l'enquête TIC 2025 de l'INSEE, publiée en juillet 2026, parmi les entreprises de 10 salariés ou plus qui n'utilisent pas l'IA, 71 % disent ne pas en voir l'utilité et 54 % évoquent un manque d'expertise. Ces réponses ne disent pas que l'IA est inutile. Elles montrent surtout que son utilité est difficile à juger en général. Elle se juge sur un problème précis.
La CNIL va dans le même sens. Dans ses questions-réponses sur l'IA générative, elle recommande de partir de besoins concrets pour choisir le système le plus adapté, en tenant compte des risques. Un besoin concret se décrit en une phrase : qui fait quoi, combien de fois, avec quelles informations, et ce qui se passe quand c'est mal fait.
Les erreurs les plus fréquentes au démarrage
Un premier projet d'IA peut décevoir sans le moindre problème technique. Il suffit que l'ordre des étapes soit inversé : la solution arrive avant le problème, ou la démonstration avant les données. Les quatre erreurs ci-dessous se repèrent tôt, à condition de savoir les reconnaître avant de signer quoi que ce soit.
- Acheter un outil d'abord. L'abonnement est souscrit parce que l'outil impressionne en démonstration, puis on cherche à quoi il pourrait servir. Sans processus visé, l'usage reste individuel et ponctuel, et personne ne peut dire ce qu'il a changé.
- Lancer un « projet IA » sans problème défini. Un projet qui porte le nom d'une technologie n'a pas de critère de réussite. Il produit des démonstrations, rarement des décisions. Un projet utile porte le nom d'un problème : les factures fournisseurs, les relances clients, le reporting mensuel.
- Ignorer les données. Une IA travaille avec les informations qu'on lui donne. Si elles sont dispersées entre des boîtes mail, des tableurs personnels et des dossiers partagés, ou si personne ne sait laquelle fait foi, le premier chantier est de les rassembler, pas de les analyser.
- Viser trop large. Vouloir transformer tous les processus à la fois retarde le moment où l'on apprend quelque chose. Un premier cas limité donne une réponse plus vite, et coûte moins cher s'il ne tient pas.
Les questions à se poser avant de choisir un outil
Avant de regarder une solution, prenez un problème candidat et répondez par écrit aux questions ci-dessous. Si vous ne pouvez pas y répondre, c'est déjà une information : le problème n'est pas encore assez clair pour être confié à un système, quel qu'il soit. Les réponses forment ensuite un cahier des charges simple, lisible par tous.
Pour départager plusieurs problèmes candidats, une grille valeur × faisabilité aide à choisir le premier. Elle fait l'objet d'un article dédié. L'objectif ici est plus modeste : s'assurer qu'au moins un problème est décrit assez précisément pour être testé, et que chacun dans l'entreprise le décrit de la même façon.
- Quel est le problème, en une phrase, et à quoi le voit-on aujourd'hui : retard, erreur, ressaisie, relance, information introuvable ?
- Qui le subit, et qui fait le travail concerné ?
- Combien de fois par semaine ou par mois la situation se présente-t-elle ?
- Où se trouvent les informations nécessaires : dans quel outil, sous quel format, et qui y a accès ?
- Quelle décision ou quelle action dépend de ce travail, et qui la valide ?
- Que coûte une erreur, et qui doit la rattraper ?
- À quoi reconnaîtra-t-on que le problème est réglé ?
Ce que l'IA fait concrètement : connecter, comprendre, agir
Le mot IA recouvre des usages très différents. Pour un dirigeant, il est plus utile de raisonner en trois verbes. Connecter : relier les outils et les données de l'entreprise, comme le CRM, l'ERP, la messagerie ou les documents partagés. Comprendre : lire, classer, résumer, détecter un écart, recommander. Agir : créer une tâche, mettre à jour une fiche, envoyer un message, dans les outils existants.
Prenons les factures fournisseurs reçues par mail. Connecter, c'est récupérer automatiquement les pièces jointes. Comprendre, c'est lire chaque facture, en extraire le fournisseur, les montants et les dates, puis repérer celles qui ne correspondent à aucune commande. Agir, c'est préparer la saisie dans l'outil comptable et signaler les écarts à la bonne personne, qui valide.
Les trois verbes ne demandent pas tous de l'IA. Connecter et agir relèvent souvent de l'automatisation classique, avec des règles fixes. L'IA devient utile pour comprendre ce qui n'est pas structuré : un texte libre, un document dont la forme varie, une demande formulée de façons très différentes. Un premier projet peut très bien être d'abord un projet de connexion.
Assistant grand public ou IA dans un processus : deux démarches
Tester un assistant conversationnel grand public, pour rédiger ou résumer, est une bonne façon de se familiariser avec l'IA et ses limites. Mais l'assistant ne connaît ni vos outils, ni vos données, ni vos règles. Il ne déclenche rien, et chacun l'utilise à sa façon. Le gain reste individuel, et difficile à mesurer pour l'entreprise.
L'INSEE fait d'ailleurs la distinction : son enquête porte sur l'usage organisé de l'IA dans les services de l'entreprise, et n'inclut en principe pas l'usage ponctuel et individuel qu'en font les salariés. Mettre l'IA dans un processus, c'est passer du second au premier : un usage défini, relié aux outils, avec un responsable et un résultat suivi.
Un point d'attention s'applique dès maintenant. La CNIL recommande de ne jamais partager d'informations confidentielles, qu'il s'agisse de données personnelles ou de données de l'entreprise, dans un service grand public. Écrire la liste des usages autorisés et interdits est un premier pas simple, utile avant même tout projet.
Ce qu'il faut réunir de votre côté
Un premier projet ne demande pas d'équipe technique interne. Il demande en revanche des éléments que seule l'entreprise peut fournir. Sans eux, même un intervenant compétent travaille à l'aveugle, et le résultat reproduit le processus officiel plutôt que le processus réel, avec ses exceptions et ses contournements.
Si des données personnelles sont traitées, celles de clients ou de salariés par exemple, l'organisme qui déploie le système doit veiller à sa conformité au RGPD, rappelle la CNIL. Mieux vaut poser la question dès le choix du problème que la découvrir au moment du déploiement.
- Un responsable métier qui porte le problème, peut arbitrer les règles et garde un peu de temps chaque semaine pour le projet.
- Une ou deux personnes qui font le travail au quotidien, pour décrire les étapes, les exceptions et les contournements, puis tester.
- Des exemples réels : documents, dossiers, messages, y compris les cas difficiles. Ce sont eux qui révèlent les limites d'une solution.
- Les accès aux outils concernés : comptes, exports, connexions possibles. Si vous ne savez pas ce qui est accessible, la question se pose à l'éditeur de l'outil.
- Des règles d'usage des données : ce qui peut être traité, par quel outil, et où les données sont hébergées.
- Un critère de réussite écrit avant de commencer, et la façon de le mesurer.
Le premier pas : un cas réel, limité et mesuré
Choisissez un seul problème, et réduisez-le à un périmètre que l'on peut tester sans risque : un type de document, une équipe, un site, une famille de demandes. Assez petit pour qu'une erreur reste rattrapable. Assez réel pour que le résultat dise quelque chose du fonctionnement normal de l'entreprise, et pas seulement d'une démonstration.
Arrêter fait partie des issues normales. Un test qui montre qu'un cas ne vaut pas la peine coûte moins cher qu'un déploiement complet qui le découvre trop tard. Chez OMEGA, la démarche suit cet ordre : comprendre le processus, prouver sur un cas réel, déployer en production, mesurer, puis améliorer.
- Décrire le processus actuel sur quelques dossiers réels, de bout en bout.
- Noter la situation de départ : volumes, délais, erreurs, temps passé, avec la source de chaque chiffre.
- Tester sur des données réelles, en gardant une validation humaine au début.
- Comparer avec la situation de départ, en séparant ce qui est mesuré de ce qui est estimé.
- Décider : élargir, ajuster ou arrêter.
Quand se faire accompagner, et quoi exiger
Un accompagnement extérieur se justifie quand le problème traverse plusieurs outils qu'il faut relier, quand les données sont sensibles, quand personne en interne n'a le temps de porter la partie technique, ou quand le système doit tourner en production, avec ses exceptions, ses contrôles et sa maintenance, et pas seulement en démonstration.
Quel que soit l'interlocuteur, prestataire ou éditeur de logiciel qui propose un module d'IA, quelques exigences simples protègent votre décision. Elles permettent aussi de repérer vite une proposition qui part de l'outil plutôt que de votre problème. Posez-les dès le premier échange.
- Qu'il commence par comprendre votre processus avant de proposer une solution.
- Qu'il teste sur vos données réelles, pas seulement sur des exemples préparés.
- Qu'il n'annonce pas de gain chiffré avant d'avoir mesuré quoi que ce soit.
- Qu'il dise où passent vos données, qui y a accès et ce qui est conservé.
- Qu'il accepte de conclure qu'un cas ne vaut pas la peine, quand c'est le cas.
- Que le système reste compréhensible et documenté pour vos équipes.
