Intelligence artificielle / Votre projet
Quels processus méritent vraiment d’être automatisés ?
Identifier les bons cas d’usage de l’intelligence artificielle dans votre entreprise — et écarter les mauvais avant qu’ils coûtent.Vous savez que vous devez faire quelque chose. Chaque service a une idée, un fournisseur a une démonstration, et personne n’a un cas d’usage écrit, mesuré, avec ses données et ses limites. Nous menons l’atelier qui transforme une envie en trois candidats, et trois candidats en un premier projet — celui qui prépare les suivants, pas celui qui impressionne le plus.
Trois façons de mal choisir son premier cas d’usage
Elles se rencontrent dans presque toutes les entreprises qui commencent. Aucune n’est une faute ; toutes coûtent un projet.
Choisir le cas le plus visible
L’agent sur le site public, l’assistant que la direction verra en démonstration. Ils impressionnent, et ils dépendent de tout ce qui n’est pas encore en place : une base de connaissance tenue, des droits relus, un propriétaire. Le premier cas visible échoue souvent pour des raisons invisibles.
Le premier cas se choisit pour ce qu’il prépare.
Partir de la technologie qu’on a envie d’essayer
Un modèle, un outil, une plateforme — et l’on cherche ensuite le problème qui va avec. Le résultat est un prototype qui tourne, que personne n’attendait, et qui s’éteint quand son parrain change de poste.
Le problème d’abord, l’outil en dernier.
Croire la procédure plutôt que la personne qui l’exécute
La procédure dit cinq étapes ; la personne en fait neuf, dont trois pour contourner un système, et elle vérifie deux choses que personne n’a écrites. Automatiser la procédure, c’est automatiser une fiction. La réalité se voit en regardant faire, pas en lisant.
On observe le processus réel, on n’automatise pas le décrit.
Cinq questions qui qualifient un processus
Posées à chaque candidat, dans cet ordre. Un processus qui répond « non » à l’une des trois premières n’est pas un premier cas d’usage — il le deviendra peut-être plus tard.
Le processus est-il fréquent ?
Combien de fois par jour, par semaine, par mois ce processus s’exécute-t-il, et combien de personnes y passent du temps ? Un processus rare, même pénible, ne rembourse pas son automatisation.
Bon signe : des dizaines d’occurrences par semaine, réparties sur plusieurs personnes. Mauvais signe : « ça arrive de temps en temps », ou une seule personne concernée.Le processus est-il ennuyeux ?
Les gens qui l’exécutent seraient-ils soulagés d’en être déchargés, ou est-ce la partie de leur travail qu’ils tiennent à garder ? Automatiser ce que les gens aiment faire échoue par l’adoption, pas par la technique.
Bon signe : recopier, chercher, trier, rapprocher, relancer. Mauvais signe : conseiller, négocier, décider, créer, rassurer.Le résultat est-il vérifiable ?
Sait-on, pour chaque exécution, si le résultat est juste ? Un traitement de factures se vérifie contre le bon de commande ; un résumé de réunion se vérifie par celui qui y était. Un processus dont on ne peut pas dire s’il a été bien fait ne se corrige jamais.
Bon signe : un système de référence, un contrôle existant, une personne qui sait. Mauvais signe : « on verra bien », ou un résultat qui n’est jugé que des mois plus tard.Ses données existent-elles, et sont-elles accessibles ?
Les documents sont-ils lisibles par une machine, les droits sont-ils clairs, le référentiel est-il propre ? Un cas d’usage dont les données n’existent pas est un projet de données avant d’être un projet d’intelligence artificielle — et c’est parfois par là qu’il faut commencer.
Bon signe : dans Microsoft 365, dans l’ERP, dans Dynamics 365, avec un propriétaire. Mauvais signe : dans la tête de deux personnes, dans des scans de travers, dans dix versions.Sait-on ce qui restera humain ?
Peut-on écrire, avant de commencer, la décision qu’une personne gardera et le moment où le système passera la main ? Si personne ne peut le dire, le cas est trop flou, ou trop risqué.
Bon signe : « la validation reste à la comptable », « l’agent envoie », « le chef de projet vérifie la source ». Mauvais signe : « le système décidera », ou l’espoir de supprimer un poste plutôt qu’une tâche.Que prépare ce cas pour les suivants ?
Le premier cas d’usage paie le rangement, les droits, l’apprentissage. Celui qui laisse derrière lui un corpus rangé, des droits relus et une équipe formée rend le deuxième et le troisième moins chers. C’est ce critère qui départage deux candidats qui ont passé les cinq questions.
Bon signe : un cas qui oblige à ranger ce que trois autres cas utiliseront.Ce que nous déconseillons d’automatiser en premier
Trois familles de processus qui reviennent dans les listes de candidats, et que nous écartons du premier projet — en l’écrivant, avec la raison.
La décision qui engage l’entreprise sans contrôle
Accepter un sinistre, accorder un crédit, répondre à un client en colère, licencier. Un modèle peut préparer ; il ne doit pas décider seul, et un premier projet n’est pas le lieu pour apprendre où placer la limite.
Le processus qui change toutes les semaines
Une organisation en réorganisation, une procédure qu’on est en train de réécrire, un système qu’on va remplacer dans six mois. Automatiser une cible mouvante, c’est reconstruire chaque mois.
Le processus dont les données n’existent pas encore
Pas de référentiel propre, pas de documents lisibles, pas de propriétaire. Le projet à mener d’abord est un projet de données — et il a sa valeur propre, quoi qu’il arrive à l’intelligence artificielle ensuite.
Une liste de processus à ne pas automatiser, argumentée
Elle évite à un service de lancer, six mois plus tard, le prototype que l’atelier avait écarté. Et elle dit ce qu’il faudrait changer — un référentiel, une procédure stabilisée, un propriétaire — pour que le cas redevienne candidat.
L’atelier d’identification : comment nous procédons
Quatre temps sur deux à trois semaines, avec les responsables métier et l’informatique dans la même pièce. Le livrable est un premier cas d’usage écrit, et la liste de ceux qui viendront après.
La collecte, auprès de ceux qui font
Une heure par service, avec les personnes qui exécutent les processus — pas seulement leurs responsables. On liste ce qui prend du temps, ce qui agace, ce qui se recopie. On regarde faire quand c’est possible.
La qualification, sur les cinq questions
Chaque candidat passe les cinq questions, avec les gens concernés. Ceux qui échouent aux trois premières sortent, avec la raison écrite. Les autres reçoivent une note de valeur, d’effort et de données.
L’architecture et le coût, à grands traits
Pour les trois ou quatre candidats restants : où sont les données, ce qui doit rester dans vos locaux, l’architecture que nous étudierions, un ordre de grandeur de coût et de durée. Assez pour choisir, pas assez pour commander.
Le choix, et la feuille de route
Le premier cas, choisi pour ce qu’il prépare ; le deuxième et le troisième, qui réutiliseront son socle ; et la décision de la direction, écrite. La suite est un projet, avec son assessment.
L’atelier est une prestation, avec un périmètre écrit et un livrable. Deux à trois semaines, quatre à six demi-journées avec vos équipes, selon le nombre de services concernés. Ce qui ne coûte rien, c’est la rencontre avec les ingénieurs qui le mèneraient — et qui mèneront le projet ensuite, parce que ce sont les mêmes.
Là où les bons premiers cas se trouvent le plus souvent
Sept familles de problèmes, et dans chacune le cas qui passe le plus souvent les cinq questions. Ce n’est pas une liste de courses : c’est là que nous regardons d’abord.
Retrouver des documents et répondre aux questions répétitives
Fréquent, ennuyeux, vérifiable par la source. Le cas qui passe le plus souvent — et qui oblige à ranger.
Automatiser les processusLes factures, les courriels, les formulaires
Vérifiable contre l’ERP, mesurable en minutes gagnées. Le cas dont le retour se calcule le plus vite.
Améliorer le service clientL’aide à l’agent et le résumé d’appel
Assiste sans remplacer, se vérifie par l’agent lui-même, prépare l’agent virtuel qui viendra ensuite.
Exploiter les connaissancesL’assistant sur un corpus confidentiel
Quand le savoir est l’actif : fréquent, vérifiable par la source, et il impose l’architecture.
Aider les équipes techniquesLe support informatique et le code
Des demandes répétitives et tracées ; un code source dont la confidentialité décide du lieu.
Observer le monde physiqueLe contrôle en bout de ligne, la surveillance d’un équipement
Fréquent et vérifiable, mais rarement un premier cas : il demande des images, des capteurs et un partenaire de vision.
Les pages qui vont avec
Ce qui vient après l’atelier, et deux articles qui traitent la même question sous un autre angle.
Du cadrage à l’exploitation au quotidien
Ce qui se passe une fois le cas choisi : assessment, prototype, industrialisation, et les livrables que vous gardez.
Voir la page ArchitecturesQuelle architecture pour votre projet ?
Sept questions, une réponse indicative — dont « je ne sais pas encore », qui renvoie ici.
Voir la page Cas d’usageToute la bibliothèque, classée par problème
Chaque cas écrit selon le même modèle en douze points, avec ce qui reste humain.
Voir la page ArticleCartographier les processus éligibles à l’automatisation
La méthode côté lecture, avec les critères que nous appliquons dans l’atelier.
Lire l’article ArticlePourquoi tant de projets d’intelligence artificielle échouent
Les causes qui se répètent, et ce que la direction peut décider pour les éviter.
Lire l’article ArticleFormer ses managers à l’ère des agents
Ce que la fonction d’encadrement doit apprendre quand une partie du travail passe à un collaborateur numérique.
Lire l’articleParlons de vos processus
Dites-nous ce qui prend du temps, et à qui
Trois processus qui agacent, les services concernés, et ce que vous avez déjà essayé. Nous revenons avec ce que nous qualifierions en premier, ce que nous écarterions, et le périmètre d’un atelier d’identification dans vos locaux.
Ce que nous offrons, c’est la rencontre des ingénieurs qui feront le travail. L’atelier d’identification est une prestation, avec un périmètre écrit et un livrable. La discussion qui le précède, elle, ne coûte rien.
Renens, Sion, Châtel-Saint-Denis
Microsoft Solutions Partner et Dell Technologies Gold Partner. Les mêmes ingénieurs de l’atelier à l’exploitation au quotidien.
Renens VD +41 21 806 37 15
Sion VS +41 27 552 00 22
Châtel-Saint-Denis FR +41 26 322 59 05