Quand une PME commence à explorer l’intelligence artificielle, la première question est souvent trop large : « Que pourrions-nous automatiser ? »
Cette formulation invite à dresser une longue liste de possibilités. Elle aide moins à choisir un point de départ fiable. Un bon premier cas d’usage ne cherche pas à démontrer tout ce que l’IA sait faire. Il résout une friction précise, dans un parcours connu, sans déplacer la responsabilité de l’équipe.
Un cas d’usage n’est pas une promesse générale
Un cas d’usage est une situation de travail délimitée dans laquelle un système produit un résultat attendu. Il doit être possible d’identifier :
- ce qui déclenche le travail ;
- les sources que le système peut consulter ;
- la sortie qu’il doit préparer ;
- la personne qui contrôle cette sortie ;
- l’action qui peut suivre après validation.
« Utiliser l’IA pour le commercial » n’est donc pas encore un cas d’usage. « Préparer le brief d’une opportunité avant un rendez-vous, à partir du CRM et des derniers échanges autorisés » en est un.
Cette précision évite de confondre une capacité technique avec une amélioration opérationnelle.
Partir d’une friction observable
Le meilleur point de départ se trouve rarement dans une démonstration spectaculaire. Il se trouve dans un travail répétitif que l’équipe connaît déjà : rechercher le contexte d’un dossier, rapprocher deux sources, vérifier qu’une information manque ou préparer une sortie avant une décision.
Une friction intéressante laisse des traces observables :
- une même recherche est refaite par plusieurs personnes ;
- un dossier revient régulièrement parce qu’il est incomplet ;
- une réunion commence par la reconstruction du contexte ;
- une prochaine action reste sans responsable ;
- une information doit être recopiée entre plusieurs outils ;
- une exception est découverte trop tard.
Le volume seul ne suffit pas. Une tâche très fréquente peut être un mauvais candidat si ses règles changent à chaque dossier. À l’inverse, une tâche moins fréquente peut créer beaucoup de valeur si elle bloque une décision importante et suit un parcours stable.
Cinq critères pour choisir
1. Le problème est suffisamment précis
L’équipe doit pouvoir décrire la situation sans parler d’IA. Quel événement déclenche le travail ? Où l’information se perd-elle ? Quelle sortie manque aujourd’hui ?
Si chacun donne une réponse différente, le processus mérite d’abord d’être clarifié. Automatiser une consigne ambiguë ne la rend pas plus fiable.
2. Les sources sont identifiées et autorisées
Une IA ne connaît pas spontanément la vérité du dossier. Elle travaille à partir des sources auxquelles elle a accès.
Il faut donc savoir quelles informations font référence : fiche CRM, email autorisé, compte rendu, document validé, ERP ou outil support. Il faut aussi définir les permissions. Le système peut-il seulement lire ? Peut-il préparer une modification ? Quels champs et quels dossiers doivent rester hors de son périmètre ?
Un cas d’usage dépendant d’informations introuvables, contradictoires ou non autorisées n’est pas prêt.
3. La sortie est utile avant toute action autonome
Un premier cas gagne à produire un résultat que l’équipe peut relire : brief, synthèse sourcée, liste de données manquantes, brouillon de tâche ou fiche d’exception.
Cette approche sépare la préparation de l’exécution. Elle permet de vérifier la qualité du système avant de lui confier une action engageante.
Par exemple, préparer un email de relance est plus facile à contrôler que l’envoyer automatiquement. Proposer une mise à jour CRM est plus prudent que modifier silencieusement une interprétation commerciale.
4. La frontière de validation est claire
La question n’est pas seulement « que peut faire l’IA ? », mais « à quel moment une personne doit-elle décider ? »
La validation est particulièrement importante lorsque la sortie touche à un prix, une promesse, une priorité, une qualification, une donnée sensible ou un message externe. La personne responsable doit voir les faits utilisés, les incertitudes détectées et l’action proposée.
Une validation utile n’est pas une formalité. Elle donne à l’utilisateur assez de contexte pour accepter, corriger ou refuser.
5. Le résultat peut être mesuré
Avant le pilote, il faut décrire la situation actuelle. Combien de reprises manuelles sont nécessaires ? Quel délai sépare le déclencheur de la sortie ? Quelles informations manquent le plus souvent ? Combien de propositions doivent être corrigées ?
Les indicateurs n’ont pas besoin d’être nombreux. Ils doivent montrer si le travail devient réellement plus fiable ou seulement plus rapide à produire.
Le taux de validation sans correction, les erreurs évitées, le délai avant prochaine action et les questions de reprise donnent souvent un point de départ plus utile que le nombre de contenus générés.
Exemple : préparer la suite d’un rendez-vous commercial
Prenons une équipe qui tient ses rendez-vous, saisit ses notes dans plusieurs espaces et met ensuite à jour le CRM. La difficulté n’est pas de générer un résumé. Elle est de transformer l’échange en contexte vérifiable.
Le cas d’usage peut être délimité ainsi :
- Déclencheur : le rendez-vous est terminé et son compte rendu est disponible.
- Sources : transcription autorisée, fiche CRM et tâches déjà ouvertes.
- Préparation : faits confirmés, objections, inconnues, décisions et prochaines actions proposées.
- Contrôle : le commercial vérifie les formulations et choisit les actions à conserver.
- Exécution : les mises à jour factuelles validées sont inscrites via l’interface prévue ; tout message externe reste un brouillon tant qu’il n’est pas approuvé.
L’équipe peut alors mesurer le délai de mise à jour, les éléments manquants et les corrections demandées. Si les propositions sont régulièrement rejetées pour la même raison, ce signal aide à corriger une source, une règle ou le format de sortie.
Les signes d’un mauvais premier cas
Certains projets doivent être recadrés avant de devenir de bons candidats :
- le résultat attendu est formulé comme « gagner du temps » sans préciser sur quel travail ;
- les décisions reposent surtout sur des règles implicites détenues par une seule personne ;
- aucune source ne fait référence ;
- l’IA devrait agir directement sur un client avant que sa préparation soit évaluée ;
- les exceptions sont nombreuses mais ne sont ni décrites ni attribuées ;
- personne n’est responsable de valider la sortie ;
- aucun indicateur ne permet de comparer l’avant et l’après.
Dans ces situations, la bonne première étape peut être une cartographie du processus, la clarification des permissions ou la structuration des données. Ce travail n’est pas un détour. Il rend l’automatisation future contrôlable.
Concevoir un pilote qui apprend
Un pilote utile doit permettre de comprendre où le système aide et où il échoue. On peut avancer par une boucle simple : observer le parcours réel, préparer une sortie sans action automatique, faire corriger cette sortie par l’équipe, puis documenter les erreurs et les exceptions récurrentes.
La réussite ne signifie pas que chaque proposition est parfaite. Elle signifie que les limites sont visibles, que les corrections sont traçables et que l’équipe sait décider si le périmètre peut être étendu.
Le bon premier cas d’usage IA ne cherche pas l’autonomie maximale. Il cherche une amélioration vérifiable dans un travail réel.
La perspective Pulse
Pulse commence par les frictions entre les outils, les équipes et les décisions. Un employé IA spécialisé peut retrouver le contexte autorisé, préparer une sortie et signaler ce qui manque. L’équipe conserve la validation des interprétations et des actions engageantes.
Choisir un premier cas d’usage revient donc à choisir une boucle de travail suffisamment précise pour être observée, testée et améliorée. C’est cette base qui permet ensuite d’étendre l’IA sans perdre la traçabilité ni le contrôle.
Sources et repères
- France Num — Baromètre France Num 2025 : adoption de l’IA et freins déclarés par les TPE-PME.
- Ministère de l’Économie — Intelligence artificielle pour les entreprises : ressources publiques pour définir et financer un projet IA.