Le choix du premier cas d'usage conditionne l'adoption. Trop petit, il ne démontre rien. Trop ambitieux, il s'enlise. Voici une méthode pour choisir un point de départ robuste.
Le premier cas d'usage n'est pas une démonstration
Beaucoup de projets IA commencent par une démonstration impressionnante. On choisit un scénario qui montre la puissance du modèle, puis on cherche ensuite à le faire entrer dans l'entreprise. Cette logique crée souvent une déception : ce qui impressionne en atelier ne tient pas forcément dans les opérations.
Un bon premier cas d'usage doit être choisi pour sa capacité à produire de la valeur réelle, pas seulement pour sa capacité à produire une bonne démo.
Il doit répondre à quatre critères :
- le travail existe déjà et coûte du temps ;
- les données nécessaires sont accessibles ;
- le risque peut être borné ;
- le résultat peut être mesuré rapidement.
Éviter les deux mauvais extrêmes
Le premier mauvais extrême est le cas trop petit. Par exemple : résumer un document isolé, reformuler un email ou générer une note ponctuelle. Ce type d'usage peut être utile, mais il ne prouve pas que l'entreprise peut augmenter une équipe.
Le second mauvais extrême est le cas trop large. Par exemple : automatiser tout le support client, transformer toute la finance ou connecter tous les outils dès le départ. Ce type de périmètre mobilise trop d'acteurs, trop de règles et trop de risques avant d'avoir appris.
Le bon premier cas d'usage est entre les deux : assez concret pour être utile, assez borné pour être gouvernable.
Une grille de sélection
Pour comparer plusieurs idées, il faut les noter avec des critères simples. Cette grille permet de sortir des débats d'opinion.
| Critère | Question | Note faible | Note forte |
|---|---|---|---|
| Fréquence | Le travail revient-il souvent ? | Occasionnel | Quotidien ou hebdomadaire |
| Clarté | Le processus est-il compréhensible ? | Flou, variable | Étapes identifiables |
| Données | Les informations sont-elles disponibles ? | Éparpillées ou sensibles | Accessibles dans un périmètre clair |
| Risque | Une erreur serait-elle grave ? | Impact client ou légal fort | Impact limité ou validable |
| Mesure | Peut-on prouver la valeur ? | Difficile à observer | Temps, volume ou qualité mesurable |
| Adoption | L'équipe en voit-elle l'intérêt ? | Usage imposé | Problème déjà reconnu |
Un bon candidat n'a pas besoin d'obtenir la note maximale partout. Mais il doit éviter les zones rouges : données introuvables, risque non borné, valeur impossible à mesurer.
Les bons premiers périmètres
Certains périmètres fonctionnent souvent mieux que d'autres pour un premier déploiement.
Préparation de décisions
Un salarié autonome peut consolider des informations, repérer des points de friction, formuler les options et préparer les arbitrages. Le décideur reste humain, mais il reçoit un dossier plus clair.
Relances et suivi
Les relances internes, commerciales, administratives ou fournisseurs sont souvent répétitives, sensibles au timing et faciles à mesurer. Le salarié autonome peut préparer, prioriser et suivre.
Contrôle de dossiers
Un salarié autonome peut vérifier des pièces, détecter les informations manquantes, comparer un statut avec une règle et préparer une liste d'anomalies.
Synthèse opérationnelle
Les équipes perdent beaucoup de temps à reconstituer ce qui s'est passé. Un salarié autonome peut produire une synthèse quotidienne ou hebdomadaire, avec sources et points d'attention.
Les mauvais premiers périmètres
Certains usages peuvent être pertinents plus tard, mais sont rarement bons en premier.
- Décisions juridiquement engageantes sans validation.
- Actions clients externes avec forte exposition réputationnelle.
- Processus mal compris par l'entreprise elle-même.
- Données dispersées sans propriétaire clair.
- Déploiements qui exigent trop d'intégrations avant de montrer une valeur.
Ces cas ne sont pas interdits. Ils demandent simplement une maturité plus élevée.
Exemple de cadrage initial
Un cadrage utile tient en une page.
cas_usage:
nom: "dossiers support en attente"
équipe: "support client"
problème:
- "les tickets restent bloqués sans relance"
- "les managers manquent de visibilité sur les causes"
salarié_autonome:
rôle: "coordinateur de dossiers en retard"
actions:
- "identifier les tickets bloqués depuis plus de 48h"
- "résumer le contexte"
- "proposer la prochaine action"
- "préparer une relance interne"
validation:
requise_pour:
- "message externe client"
- "changement de priorité critique"
mesure:
- "nombre de tickets débloqués"
- "temps moyen avant relance"
- "volume d'escalades utiles"
Checklist avant de lancer
- Le problème est déjà reconnu par l'équipe.
- Le périmètre tient dans une fonction et un flux de travail.
- Le salarié autonome peut agir sans toucher à des décisions irréversibles.
- Les sources nécessaires sont connues.
- Un manager métier accepte de superviser les premières semaines.
- Les critères de succès sont écrits avant le lancement.
- Les cas d'exception ont été simulés.
Le bon rythme
Un premier cas d'usage doit être piloté comme un apprentissage court. Deux à quatre semaines suffisent souvent pour savoir si le périmètre est bon, si les règles sont claires et si l'équipe y trouve une valeur.
La question à la fin n'est pas seulement : "Est-ce que ça marche ?" La bonne question est : "Qu'avons-nous appris pour étendre proprement ?"
Un bon premier cas d'usage devient une référence interne. Il donne un modèle de cadrage, de validation, de mesure et d'adoption pour les autres équipes.