Prioriser les cas d’usage IA : construire un portefeuille pilotable

Prioriser des cas d’usage IA ne consiste pas à choisir l’idée qui impressionne le plus pendant un atelier. Une organisation doit comparer des problèmes de travail, des personnes concernées, des données disponibles, des effets possibles et une capacité réelle de conduite du changement. Elle doit aussi accepter qu’un cas prometteur puisse rester en attente parce qu’il n’a pas encore de propriétaire, de référence mesurable ou de moyen sûr d’être testé.

La méthode la plus robuste applique deux décisions successives. La première élimine les cas qui ne doivent pas avancer dans leur forme actuelle. La seconde compare les cas admissibles sans réduire le risque à quelques points noyés dans une moyenne. Le résultat n’est pas un « top des idées IA », mais un portefeuille révisable : quelques explorations, un nombre limité de pilotes et une file d’attente documentée.

Réponse en bref

Pour prioriser un portefeuille de cas d’usage IA :

1. décrivez chaque problème sans présumer que l’IA est la solution ;
2. exigez une décision métier, un propriétaire et une situation de référence ;
3. éliminez provisoirement les cas sans finalité claire, sans voie licite d’accès aux données, sans contrôle proportionné, sans population de test ou sans solution de repli ;
4. comparez séparément la valeur attendue, la faisabilité, l’adoption et l’apprentissage produit par un pilote ;
5. gardez les risques bloquants hors du score moyen ;
6. répartissez les cas entre exploration, pilote borné et attente ;
7. ne lancez que le nombre de pilotes que l’équipe peut réellement mesurer et superviser ;
8. revoyez le portefeuille après chaque nouvelle preuve, pas seulement à la fin du budget annuel.

La prochaine action utile est de sélectionner cinq problèmes déjà observés, puis de remplir pour chacun la même fiche d’une page. Si une idée ne permet pas de nommer la décision, la personne concernée et la référence actuelle, elle n’est pas encore prête à être comparée.

Partir des problèmes observables, pas d’un catalogue IA

Un inventaire faible contient des formulations comme « assistant commercial », « chatbot RH » ou « agent autonome ». Ces expressions décrivent une famille de solutions, pas un cas d’usage. Elles ne disent pas qui travaille, quelle sortie est attendue, quelle erreur compte ni ce qui se passe aujourd’hui.

Reformulez chaque entrée ainsi :

Pour ce type de situation, ce rôle doit produire ou décider ce résultat, avec ces informations, avant cette échéance.

« Résumer des demandes entrantes pour préparer leur affectation » est déjà plus exploitable que « faire un agent de support ». La première formulation permet de regarder le volume, le temps d’attente, les catégories, les données contenues dans les demandes et la personne qui reste responsable de l’affectation. Elle laisse aussi ouverte la possibilité qu’une règle déterministe, un formulaire mieux conçu ou une amélioration du processus soit préférable à l’IA.

Le guide britannique sur l’adoption de l’IA recommande de partir des besoins des utilisateurs et de concentrer l’effort sur les cas que l’IA seule peut traiter, ou pour lesquels elle apporte un avantage significatif par rapport aux techniques existantes. Cette règle évite d’utiliser un modèle génératif pour résoudre un défaut de formulaire, un référentiel incomplet ou une règle métier déjà parfaitement explicite.

Avant d’ajouter une idée au portefeuille, demandez donc :

• quel événement déclenche le travail ;
• quel rôle reçoit l’entrée ;
• quelle sortie est produite ;
• qui utilise ou valide cette sortie ;
• quel délai ou défaut est observé aujourd’hui ;
• quelle technique non IA pourrait aussi résoudre le problème.

Une idée qui survit à cette reformulation devient un cas candidat. Elle ne devient pas encore une priorité.

Écrire une fiche comparable pour chaque cas

Les ateliers de priorisation échouent souvent parce que certaines idées disposent d’un dossier complet et d’autres d’une phrase. La comparaison favorise alors la personne la plus convaincante, pas le cas le mieux préparé.

Utilisez une fiche identique pour chaque candidat :

Champ	Question à renseigner
problème	quelle friction observable cherche-t-on à réduire ?
décision ou sortie	quel résultat précis doit être produit ou mieux préparé ?
personne concernée	qui utilise, subit ou contrôle le résultat ?
référence actuelle	volume, délai, qualité, reprises ou coût aujourd’hui
données	quelles informations sont nécessaires, disponibles et autorisées ?
erreur critique	quel résultat ne doit jamais être accepté ?
effet externe	le système informe, propose, modifie, envoie ou décide-t-il ?
propriétaire	qui arbitre le périmètre et accepte le résultat du pilote ?
solution de repli	comment le travail continue-t-il si le test s’arrête ?
preuve suivante	quelle incertitude un test court doit-il lever ?

La fiche doit conserver les inconnues. Écrire « volume non mesuré » est plus utile que d’inventer un gain annuel. Cette absence indique la prochaine recherche à mener. Elle peut faire passer le cas en exploration sans le rejeter définitivement.

La situation de référence mérite une attention particulière. L’article consacré au ROI d’un cas d’usage IA explique comment construire une baseline et comparer un pilote. Au stade du portefeuille, il ne s’agit pas encore de calculer un rendement complet. Il faut vérifier qu’une observation future sera possible : existe-t-il un dénominateur, des dossiers comparables et un critère d’acceptation ?

Appliquer cinq filtres éliminatoires avant toute note

Un score ne doit pas rendre admissible un cas qui ne l’est pas. Appliquez d’abord cinq filtres. Un échec ne signifie pas toujours « abandon ». Il signifie « ne pas piloter dans cette forme ».

1. Finalité et responsabilité

Le problème, la sortie et le propriétaire doivent être nommés. Si personne ne peut accepter le résultat, arrêter le test ou financer le processus après la démonstration, le cas n’a pas de responsabilité opérationnelle.

2. Données accessibles dans un cadre défini

L’équipe doit savoir quelles catégories de données entrent dans le système, d’où elles viennent et qui autorise leur usage. « Nous verrons avec les vraies données plus tard » repousse précisément le risque que le pilote devrait révéler. Un test synthétique peut servir à explorer la technique, mais ne valide pas l’usage réel.

3. Usage juridiquement et humainement examinable

Les usages interdits ou potentiellement à haut risque ne se traitent pas avec un bonus de prudence dans une feuille de calcul. La Commission européenne rappelle que la qualification dépend notamment de la finalité prévue et de catégories d’usage précises, par exemple dans l’emploi, l’éducation, l’accès à certains services ou la biométrie. Si le cas touche ces domaines, l’examen approprié doit précéder le pilote opérationnel. Une auto-évaluation rapide ne remplace pas un conseil compétent.

4. Contrôle placé avant l’effet

Si le système peut envoyer un message, modifier un dossier, déclencher un paiement ou influencer une décision concernant une personne, le point d’arrêt doit être connu. Une validation prévue après l’action ne contrôle rien. Le cas peut être reformulé en mode lecture ou proposition afin de rendre le test réversible.

5. Population de test et solution de repli

Un pilote a besoin de cas représentatifs, y compris des exceptions, et d’un chemin manuel si le système s’arrête. Le Data and AI Ethics Framework britannique indique qu’un système dont les risques ne peuvent pas être suffisamment réduits ne doit pas être utilisé pour traiter le problème. Le portefeuille doit donc pouvoir conserver une décision d’arrêt sans la présenter comme un retard technique.

Comparer quatre dimensions sans fabriquer une précision

Les cas qui passent les filtres peuvent être comparés sur quatre dimensions. Une échelle courte, de faible à forte, suffit au premier atelier. Chaque appréciation doit comporter une justification observable.

Valeur du problème

La valeur décrit l’importance du problème, pas le prestige de la solution. Regardez la fréquence, le délai, la qualité, les reprises, les erreurs et la conséquence sur la prochaine étape. Un irritant fréquent peut être prioritaire même si son gain unitaire paraît modeste. Une tâche rare mais critique peut aussi compter, sans être présentée comme un gisement de productivité.

Faisabilité du test

Évaluez la disponibilité d’exemples, la stabilité de la sortie, les intégrations, les compétences, le coût de contrôle et le temps nécessaire pour obtenir une preuve. La faisabilité d’un pilote n’est pas celle d’une démonstration. Elle inclut la préparation, la vérification, la journalisation et la reprise.

Adoption et désirabilité

Une personne doit avoir intérêt à utiliser la sortie et pouvoir contester une erreur. Le cadre de Microsoft consacré aux agents sépare lui aussi impact métier, faisabilité technique et désirabilité utilisateur. Interrogez les rôles concernés avant de conclure que le temps gagné sera bienvenu. Une automatisation peut déplacer une charge vers la vérification ou supprimer une information utile à la coopération.

Valeur d’apprentissage

Le meilleur premier test n’est pas toujours le cas à plus forte valeur théorique. Il peut être celui qui lève une incertitude partagée par plusieurs futurs cas : qualité d’un référentiel, délai d’une API, capacité de revue, acceptation d’un rôle ou fonctionnement d’une permission. Cette dimension transforme le portefeuille en séquence d’apprentissage plutôt qu’en concours de promesses.

Utilisez une table lisible, sans décimales :

Cas	Valeur	Faisabilité du test	Adoption	Apprentissage	Incertitude principale
candidat A	forte	moyenne	forte	forte	qualité des données d’entrée
candidat B	moyenne	forte	moyenne	faible	usage réel de la sortie
candidat C	forte	faible	inconnue	forte	intégration et contrôle

Le tableau n’ordonne pas automatiquement les lignes. Il rend les désaccords discutables.

Ne pas compenser un risque bloquant par une bonne moyenne

Une moyenne pondérée peut aider à trier un grand inventaire, mais elle devient dangereuse si une note élevée de valeur compense une absence de contrôle ou une donnée non autorisée. Conservez donc deux objets séparés : les dimensions de comparaison et les conditions bloquantes.

Évitez aussi les pondérations décidées après avoir vu le résultat. Si la direction augmente soudain le poids du « potentiel stratégique » pour faire remonter son idée favorite, la matrice ne protège plus l’arbitrage. Écrivez les critères avant la notation, documentez les hypothèses et gardez la possibilité d’un verdict « preuve insuffisante ».

Un cas très visible peut rester en exploration. Un cas modeste peut entrer en pilote s’il est réversible, mesurable et utile pour apprendre. La priorité décrit la prochaine dépense d’attention, pas la valeur définitive du projet.

Construire trois files de décision

Après la revue, chaque cas rejoint une seule file.

Exploration

L’exploration vise à lever une inconnue sans prétendre tester la valeur complète. Elle peut mesurer le volume réel, annoter un échantillon, interroger les utilisateurs, vérifier la qualité des données ou comparer une règle simple à un modèle. Elle possède une question, un responsable, une durée courte et un livrable.

Pilote borné

Le pilote compare un nouveau processus à une référence sur un périmètre réel mais limité. Il dispose d’un critère d’acceptation, de cas difficiles, d’un contrôle humain, d’une solution de repli et d’une date de décision. Il ne s’étend pas automatiquement parce qu’une démonstration a plu.

Attente documentée

La file d’attente contient une raison et un déclencheur de réexamen : données indisponibles, propriétaire absent, dépendance non livrée, risque à instruire, outil trop coûteux ou processus en cours de refonte. « Plus tard » n’est pas une décision. « Réexaminer après six semaines de baseline » en est une.

Il faut également une quatrième issue, définitive ou longue : retirer le cas lorsque le problème n’existe pas, qu’une solution non IA suffit ou que les effets ne sont pas acceptables. Un portefeuille sain sait perdre des idées.

Arbitrer la capacité et les dépendances

Une organisation peut identifier dix cas admissibles et ne pouvoir en piloter que deux. Cette limite doit apparaître dans la décision. Comptez la disponibilité du métier, de la technique, de la sécurité, du juridique, de la donnée et des évaluateurs. Un pilote sans temps de revue crée seulement une file de sorties non vérifiées.

Cartographiez ensuite les dépendances communes : annuaire, classification des données, API, référentiel, jeu de tests, journalisation, environnement isolé ou procédure d’incident. Si trois cas dépendent du même référentiel incomplet, lancer trois prototypes ne diversifie pas le portefeuille. Cela répète trois fois le même blocage.

Une fois le cas retenu, la méthode build vs buy IA permet de comparer SaaS, API, solution hébergée et développement spécifique sans rouvrir la priorisation du besoin.

La séquence peut alors devenir : fiabiliser le référentiel, explorer un cas représentatif, piloter un seul flux, puis réévaluer les deux autres. Cette logique rejoint le Cloud Adoption Framework : la maturité, les ressources, les données et l’infrastructure doivent entrer dans la priorisation, pas être découvertes après la sélection.

Exemple synthétique d’arbitrage

Imaginons une organisation qui examine cinq idées : résumer des dossiers, classer des demandes, rédiger des réponses, rechercher dans une base interne et envoyer automatiquement une relance.

La relance automatique échoue au filtre de contrôle si elle doit partir sans validation et si l’état du destinataire n’est pas fiable. Elle est reformulée en proposition de relance. La recherche interne passe en exploration parce que les documents ne possèdent pas encore de propriétaire ni de date de validité. Le résumé de dossier possède des exemples, une personne qui valide et un résultat comparable ; il peut entrer en pilote. Le classement des demandes dépend du même référentiel que la recherche, il attend sa correction. La rédaction de réponses reste en exploration tant que l’équipe n’a pas défini ce qu’est une réponse acceptable.

Le portefeuille ne proclame pas que « le résumé est le meilleur cas d’usage IA ». Il dit seulement : c’est la prochaine hypothèse que l’organisation peut tester proprement. Les autres décisions sont accompagnées de la preuve manquante.

Organiser une revue mensuelle du portefeuille

La revue ne doit pas devenir un comité de présentation. Pour chaque cas actif, affichez : dernière preuve, hypothèse encore ouverte, consommation de capacité, incident éventuel, décision suivante et date. Un cas peut passer de pilote à attente si la qualité des données se dégrade. Une exploration peut être retirée si une règle déterministe atteint le résultat attendu.

Lorsque plusieurs fonctions doivent autoriser, limiter ou arrêter ces cas, le protocole du comité IA en entreprise sépare la revue du portefeuille de l’arbitrage collectif, puis attribue chaque condition et sa preuve.

Ajoutez les nouveaux cas avec la même fiche, sans changer les critères. Archivez les anciennes versions afin de comprendre pourquoi une décision a évolué. Le registre des cas conseillé par le playbook britannique sert précisément à maintenir cette continuité entre idées, recherche, changement et surveillance.

Si un consultant intervient, demandez-lui de rendre le registre, les hypothèses, les exclusions et les règles de décision, pas seulement une présentation finale. Le cahier des charges d’une mission de conseil IA aide à traduire ce besoin en livrables et critères d’acceptation.

Limites

Cette méthode n’est ni une qualification juridique, ni une estimation financière complète, ni une preuve de faisabilité technique. Les catégories de l’AI Act et les obligations sectorielles doivent être examinées à partir du système, de sa finalité et de son contexte réels. Les cadres Microsoft et britanniques cités sont des guides d’adoption, pas des normes universelles.

Une appréciation faible, moyenne ou forte dépend aussi des personnes présentes. Réunissez plusieurs rôles, consignez les désaccords et revenez aux preuves. Un portefeuille de dix idées ne mérite pas forcément dix pilotes. Enfin, un cas bien priorisé peut échouer pendant le test ; le but du dispositif est justement de rendre cet échec rapide, explicable et réversible.

Articles liés

• Mesurer le ROI d’un cas d’usage IA
• Choisir entre RPA, workflow et agent IA
• Évaluer un assistant IA avant son déploiement