Cas d’usage
Vous pensez que l’IA pourrait aider. Encore faut-il savoir où.
La question n'est pas de savoir si l'IA est capable de faire quelque chose — elle l'est souvent. Elle est de trouver l'étape précise de votre processus où elle change réellement quelque chose, de vérifier que vos données le permettent, et de décider ce qui se passe quand le résultat est faux.
Vous vous reconnaissez peut-être
Les situations où l'IA apporte quelque chose ont un point commun : beaucoup de lecture, de tri et de recherche, peu de décision.
- Vos équipes passent du temps à chercher une information qui existe déjà quelque part.
- L'information utile est dans des documents, des e-mails ou des PDF, pas dans une base exploitable.
- Des demandes en texte libre doivent être triées avant d’être traitées.
- Les mêmes questions reviennent et reçoivent des réponses reformulées à chaque fois.
- Il faut lire de gros volumes pour en extraire quelques éléments : contrats, rapports, comptes rendus.
- Préparer une décision demande de rassembler des éléments dispersés avant même de pouvoir l'instruire.
Ce qui se passe si on s’y prend mal
Le risque principal n'est pas l'absence d'IA. C'est un projet d'IA qui consomme du budget sans jamais atteindre la production.
- Le prototype impressionne et reste un prototype
- Une démonstration qui fonctionne sur quelques exemples bien choisis ne dit rien du comportement sur un volume réel, avec des cas dégradés et des utilisateurs pressés.
- La qualité ne se mesure pas
- Sans jeu de cas de référence, la discussion sur la fiabilité devient une affaire d'impressions. On ne peut ni comparer deux approches, ni détecter une dégradation.
- La responsabilité devient floue
- Si personne n'a défini qui valide quoi, une erreur du système devient un problème sans propriétaire. C'est ce qui fait abandonner un outil après quelques incidents.
- Le coût réel apparaît après la mise en service
- Appels facturés à l'usage, volumes plus élevés que prévu, reprises manuelles : le coût d'exploitation se découvre en production si personne ne l'a estimé avant.
Où l’IA peut intervenir dans un processus
Ce ne sont pas des produits mais des types d'intervention. Chacun s'insère à un endroit précis, et chacun suppose des conditions différentes.
| Où l’IA peut intervenir dans un processus | Quand c’est pertinent | Ce que cela suppose |
|---|---|---|
| Recherche augmentée | L'information existe dans vos documents mais personne ne la retrouve assez vite. | Des documents accessibles et à jour, et des réponses qui citent leurs sources pour être vérifiables. |
| Classification | Des éléments entrants doivent être orientés vers le bon traitement : demandes, tickets, documents. | Des catégories stables et un historique de cas déjà classés pour mesurer la justesse. |
| Extraction | Des données utiles sont enfermées dans des documents peu structurés : factures, contrats, formulaires. | Des contrôles de cohérence en sortie, et un rapprochement avec vos référentiels avant enregistrement. |
| Génération assistée | Des textes récurrents sont rédigés à la main à partir des mêmes éléments : réponses, comptes rendus, synthèses. | Vos modèles et vos règles comme cadre, et une relecture humaine avant tout envoi externe. |
| Détection de cas atypiques | Un volume important passe en routine et il faut repérer ce qui mérite un regard. | Assumer que le système signale plus qu'il ne tranche : la sortie est une file à vérifier, pas une décision. |
Plusieurs de ces besoins se traitent mieux sans IA générative : pour extraire des champs d'un formulaire fixe ou classer selon des critères stables, une approche plus simple est souvent plus fiable et moins chère.
Une étape assistée, pas un processus remplacé
Le processus reste le vôtre. L'IA intervient là où se trouve la friction, et son résultat repasse par une validation avant de continuer son chemin.
- 01
Réception
- 02
Qualification
- 03
Préparation assistée
- 04
Validation humaine
- 05
Traitement
- 06
Clôture
Si l'étape assistée devient indisponible, le processus doit pouvoir continuer comme avant. C'est une condition de mise en production, pas une option.
Comment nous abordons le problème
On part du processus et de la donnée. Le choix de la technique vient à la fin, quand la question est posée correctement.
- 01
Trouver la friction réelle
Quelle étape prend du temps, qui la fait, combien de fois par semaine, et que se passe-t-il quand elle est mal faite. Sans cette étape, on optimise quelque chose qui n'avait pas d'importance.
- 02
Regarder les données disponibles
Volume, qualité, format, droits d'usage. Il arrive que la conclusion soit qu'il faut d'abord traiter la donnée — et que ce chantier ait plus de valeur que le projet d'IA lui-même.
- 03
Constituer un jeu de référence
Des cas réels avec la bonne réponse attendue, validés par vos équipes métier. C'est ce qui permet de mesurer, de comparer des approches et de détecter une dégradation plus tard.
- 04
Évaluer sur ce jeu
Un test mesuré, pas une démonstration. Le résultat indique si le niveau est suffisant pour l’usage visé, et à partir de quel seuil de confiance une vérification humaine est nécessaire.
- 05
Définir le comportement en cas d’erreur
Seuil de confiance, chemin de vérification, repli sur le traitement classique, traçabilité de chaque résultat. Un système sans ces éléments n'est pas prêt pour la production.
- 06
Intégrer dans le processus existant
L'assistance apparaît dans les outils que les équipes utilisent déjà. Une interface séparée qu'il faut penser à ouvrir se fait oublier en quelques semaines.
- 07
Surveiller dans la durée
Qualité mesurée régulièrement sur le jeu de référence, volume de cas partis en vérification, coût réel d'exploitation. Les données dérivent et les modèles changent de version.
Trois questions avant de mettre de l’IA
Si l'une des trois n'a pas de réponse, le projet n'est pas prêt — quelle que soit la qualité de la démonstration.
- 1
Avons-nous les bonnes données ?
Accessibles, suffisamment complètes, à jour, et que vous avez le droit d'utiliser pour cet usage. Une IA performante sur des données inexactes produit des erreurs plus vite.
- 2
Pouvons-nous mesurer si le résultat est suffisamment bon ?
« Suffisamment bon » se définit avant de commencer, sur un jeu de cas réels, avec un seuil décidé par le métier. Sans cette définition, personne ne saura dire si le projet a réussi.
- 3
Que se passe-t-il lorsque le modèle se trompe ?
Qui le détecte, à quel coût, et que fait le processus ensuite. Une erreur rattrapée par une validation est un cas prévu ; une erreur qui part chez un client est un incident.
Un prototype n’est pas un produit
Un prototype qui fonctionne sur vingt exemples démontre qu'une piste existe. Il ne démontre pas qu'elle tiendra en production.
Les données changent d’échelle
Sur le volume réel apparaissent les formats inattendus, les documents illisibles et les cas que personne n’avait montrés pendant la démonstration.
La confidentialité devient une décision
En production, il faut trancher où les données sont traitées, ce que le fournisseur s'engage à ne pas réutiliser, et ce qui est conservé. Cela peut changer l'architecture.
Le coût devient récurrent
Un appel facturé à l'usage multiplié par le volume quotidien donne un chiffre qu'il vaut mieux connaître avant la mise en service que dans la facture du premier mois.
La version du modèle bouge
Les fournisseurs font évoluer leurs modèles. Sans jeu de référence et sans version épinglée, une amélioration annoncée peut dégrader votre cas précis sans prévenir.
Le repli doit exister
Indisponibilité, cas hors domaine, dépassement de quota : le processus doit continuer autrement. Un traitement qui s'arrête parce que l'IA ne répond pas n'est pas exploitable.
Ce que cela peut donner
Des formes que prend une intégration réussie, toujours sur une étape précise plutôt que sur le processus entier.
- Une recherche dans la documentation interne qui renvoie la réponse avec ses sources
- Un tri automatique des demandes entrantes, avec les cas douteux orientés vers un humain
- Une extraction des données d’un document, contrôlée avant enregistrement
- Une aide à la rédaction encadrée par vos modèles, relue avant envoi
- Un signalement des dossiers atypiques dans un flux traité en routine
- Un tableau de suivi de la qualité mesurée, pour voir une dérive avant les utilisateurs
Ces exemples décrivent des formes de solution possibles, pas des projets réalisés présentés comme références.
Cette trajectoire peut mobiliser
Le cadrage du processus vient avant le choix technique. L'intégration dans vos outils existants vient après.
Questions fréquentes
Faut-il entraîner notre propre modèle ?
Rarement, et jamais en première étape. Les approches basées sur des modèles existants, associées à vos documents et à vos règles, couvrent la grande majorité des besoins métier. Entraîner un modèle spécifique demande un volume de données annotées important et un coût d'entretien continu — cela se décide après avoir mesuré que rien d'autre ne suffit.
Peut-on utiliser nos données confidentielles ?
Cela dépend de l'architecture retenue, et c'est une décision à prendre explicitement au cadrage. Selon la sensibilité, on passe par une API commerciale assortie d'engagements contractuels de non-réutilisation, ou on héberge le traitement dans un environnement que vous maîtrisez. Chaque option a un coût et des contraintes que nous documentons avant que vous choisissiez.
Comment mesurer si l’IA fonctionne ?
Sur un jeu de cas réels dont la bonne réponse a été validée par vos équipes métier, et avec un seuil décidé à l'avance. C'est la seule mesure qui ait du sens : une performance annoncée sur un jeu de test public ne dit rien de votre situation. Ce jeu sert ensuite à surveiller la qualité dans le temps.
Comment gérer les erreurs du modèle ?
En les traitant comme un cas prévu. Sous un seuil de confiance, le cas part en vérification humaine plutôt que de passer en silence. Les décisions qui engagent restent validées par une personne. Et quand le modèle est indisponible ou sorti de son domaine, le processus repasse par le traitement classique.
Faut-il commencer par un POC ?
Une évaluation courte sur vos données réelles, oui. Un POC « vitrine » sur des exemples choisis, non : il ne prouve rien et consomme du temps. La différence tient au jeu de cas utilisé et au fait de mesurer un résultat plutôt que de montrer une capacité.
Parlons de votre processus
Décrivez-nous l'étape où vos équipes passent le plus de temps à chercher ou à trier. C'est là que la question se pose utilement.