Quel premier cas d’usage IA choisir ?
Le premier cas d’usage IA à choisir n’est pas le plus visible, c’est celui qui réunit cinq conditions : un problème que quelqu’un a déjà mesuré à la main, des documents accessibles et sans contrainte forte, un résultat qu’un humain peut vérifier, un volume qui justifie l’effort, et un propriétaire côté métier. Le reste vient après.
Cet article conclut une série de dix. Chaque critère renvoie à l’article qui le développe ; la liste complète est à la fin.
Pourquoi le premier cas d’usage compte-t-il plus que les suivants ?
Parce qu’il fixe, pour longtemps, ce que l’entreprise pense de l’IA. Un premier projet qui s’arrête après la démonstration ferme la porte : la direction retient que « ça ne marche pas chez nous », et la demande suivante attendra deux ans. Un premier projet modeste qui tourne, qu’on mesure et que ses utilisateurs ouvrent chaque jour ouvre la porte à tous les autres, y compris aux plus ambitieux.
Le piège est connu : choisir le cas le plus impressionnant, celui qui plaît en réunion, plutôt que celui qui a une chance d’atteindre la production. Les raisons pour lesquelles les POC s’arrêtent sont presque toutes visibles au moment du choix, pour qui accepte de regarder.
Quels critères éliminent d’emblée ?
Trois exclusions, à passer avant d’aller plus loin.
Le problème se résout sans IA. Retrouver un document par sa référence, filtrer des dossiers par date, vérifier qu’un champ est rempli : une recherche plein texte ou une règle font mieux, plus vite et pour moins cher. Le réflexe utile est d’écrire dix questions réelles et de compter celles qu’un filtre résout ; j’ai détaillé ce test ailleurs. Si sept sur dix se résolvent sans modèle, ce n’est pas un premier cas d’usage IA.
Le cas touche aux personnes de façon sensible ou décisionnelle. Trier des candidatures, évaluer des salariés, décider d’un accès ou d’un crédit : le règlement européen sur l’IA classe ces usages à haut risque, avec des obligations lourdes pour celui qui déploie, et le RGPD y ajoute les siennes. Ce n’est pas un premier cas, c’est un dossier.
Les données ne peuvent ni sortir ni être hébergées dans un délai raisonnable. Si les documents concernés ne peuvent pas transiter par un fournisseur et que l’entreprise n’a ni serveur ni budget pour héberger un modèle, le premier cas d’usage attendra que l’une des deux conditions change. Ce que les fournisseurs font des données et comment arbitrer entre ouvert et API disent quand ce blocage est réel et quand il ne l’est pas.
Quels critères font un bon premier cas ?
Cinq, et chacun a un signe qui le révèle en réunion.
- Un problème déjà mesuré à la main. Le signe : quelqu’un sait dire « ça nous prend trois heures par jour » ou « on répond en deux jours au lieu de deux heures ». Sans mesure avant, il n’y aura pas de mesure après, et personne ne pourra dire si le projet a servi.
- Des documents accessibles et sans contrainte forte. Le signe : « c’est dans un seul outil, et tout le monde y a accès ». Un corpus éparpillé sur quatre partages réseau, avec des droits différents et des PDF scannés, est un projet d’extraction avant d’être un projet d’IA.
- Un résultat qu’un humain peut vérifier. Le signe : « le métier saura dire si c’est juste ». C’est ce qui permet d’écrire le jeu d’évaluation et de relire les premières réponses. Un cas dont personne ne peut juger la sortie ne se mesure pas.
- Un volume qui justifie l’effort. Le signe : « ça arrive plusieurs fois par jour ». Un cas qui se présente dix fois par mois ne produit ni assez de données pour évaluer, ni assez de gain pour justifier l’exploitation. Ce que coûte un assistant se compare à ce qu’il économise, et le volume est dans les deux termes.
- Un propriétaire côté métier, nommé. Le signe : quelqu’un dit « je veux cet outil » et a du temps pour valider. Sans lui, le projet appartient à la DSI, et un outil que le métier n’a pas demandé est un outil que personne n’ouvre.
Un cas qui réunit les cinq est rare ; un cas qui en réunit quatre est un bon candidat, à condition que le cinquième soit le volume ou les documents, pas le propriétaire ni la mesure.
À quoi ressemble un bon premier cas, et un mauvais ?
Un bon premier cas : préparer une réponse de premier niveau au support, à partir de la base de procédures, sans l’envoyer. Le temps de réponse est mesuré, les procédures sont dans un outil, le technicien qui relit sait si la réponse est juste, les demandes arrivent toute la journée, et le responsable du support veut l’outil. La validation humaine reste dans la boucle, donc une erreur ne coûte qu’une relecture. Quand le jeu d’évaluation montre que les réponses tiennent, l’étape suivante, envoyer sans relecture sur les cas simples, se décide sur des chiffres.
Un mauvais premier cas : l’assistant qui répond à tout le monde sur tous les documents de l’entreprise. Pas de mesure préalable, parce qu’il ne remplace aucune tâche précise ; un corpus qui mélange tout, y compris ce qui ne devrait pas être accessible à tous ; un résultat que personne ne peut juger, parce que la question peut porter sur n’importe quoi ; et un propriétaire introuvable, parce que l’outil est à tout le monde. Il impressionne en démonstration et il s’arrête après, pour les raisons de l’article sur les POC.
Pour d’autres exemples, à petite échelle, cinq processus concrets sont décrits dans un article plus ancien du site.
Comment j’ai choisi le mien ?
Par la même grille, avant de savoir que c’en était une. Mnemo, mon moteur de recherche sur mes propres notes, est né d’un problème mesuré à la main : je passais du temps à retrouver des notes que je savais avoir écrites, et la recherche par mots-clés échouait dès que je n’avais plus le terme exact. Les documents étaient accessibles, un seul dossier de notes ; le résultat était vérifiable, je savais quelle note j’attendais ; le volume était quotidien ; et le propriétaire, c’était moi.
Ce choix a rendu le reste possible. Le jeu d’évaluation s’est écrit en une heure, parce que je connaissais les questions. La décision de modèle s’est prise sur des chiffres, parce que la mesure existait. Le système tourne depuis mai 2026, avec sa supervision et sa réindexation automatique, parce qu’un cas qu’on utilise tous les jours finit par recevoir ce qu’il faut pour tenir.
J’ai aussi le contre-exemple, et il est à moi. Thadeus est un modèle de langue que j’ai entraîné de zéro sur mon Mac : cent dix heures de calcul, chaque étape mesurée et publiée. C’est un projet d’apprentissage dont je suis content, et il ne remplace aucune tâche. Passionnant, sans usage direct, sans propriétaire autre que ma curiosité : comme premier cas d’usage pour une entreprise, il aurait tout faux. Les deux projets ont le même auteur et la même rigueur ; un seul a un usage. C’est la différence que la grille sert à voir.
Combien de temps pour décider ?
Le temps d’un cadrage, tel que je le pratique : quatre temps, sur deux à cinq jours selon le périmètre. Écouter les personnes qui font le travail et celles qui exploitent le SI, pas seulement le sponsor. Tester sur les vraies données, avec un jeu d’évaluation écrit avec le métier. Situer le cas dans le SI, sources, droits, hébergement, coût d’exécution. Trancher : lancer, préparer, ou écarter, avec les raisons.
C’est souvent le refus qui est le plus utile. Un cadrage qui conclut « pas celui-là, pas maintenant, voici pourquoi et voici celui qui conviendrait » a évité un projet mort et en a trouvé un vivant. Le livrable reste à l’entreprise, quelle que soit la suite.
Par où commencer ?
Par la grille, à remplir en réunion pour chaque candidat, par oui ou par non.
| Critère | Candidat A | Candidat B | Candidat C |
|---|---|---|---|
| Se résout sans IA ? (si oui, éliminer) | |||
| Touche aux personnes de façon sensible ou décisionnelle ? (si oui, dossier à part) | |||
| Données bloquées sans solution d’hébergement ? (si oui, attendre) | |||
| Problème déjà mesuré à la main | |||
| Documents accessibles, un seul outil, droits clairs | |||
| Résultat vérifiable par le métier | |||
| Plusieurs occurrences par jour | |||
| Propriétaire côté métier, nommé |
Le candidat qui passe les trois exclusions et réunit au moins quatre critères sur cinq est le premier cas d’usage. S’il n’y en a aucun, c’est une information utile : l’entreprise a d’abord un problème de données ou de mesure, et c’est par là qu’il faut commencer.
Cette série a été écrite dans l’ordre où les questions se posent. Pour la lire en entier :
- Combien coûte un assistant IA sur les documents internes d’une entreprise ?
- RAG ou fine-tuning : lequel choisir pour ses documents métier ?
- Nos données partent-elles chez OpenAI quand on utilise un LLM ?
- Pourquoi les POC IA n’arrivent jamais en production ?
- Comment évaluer un système RAG ? Les métriques qui comptent
- LLM open source auto-hébergé ou API propriétaire : comment arbitrer ?
- Combien coûte l’hébergement d’un LLM en interne ?
- Agent IA connecté au SI : quels connecteurs, quelle sécurité ?
- IA et RGPD : héberger ses traitements en France, ce que ça implique vraiment
Si vous avez un ou plusieurs candidats et que la grille ne suffit pas à trancher, décrivez votre cas d’usage : la première réponse sera de vous dire lequel passe la grille, et pourquoi.