Chaque comité de pilotage IA auquel nous assistons rencontre le même problème, et ce n'est pas un manque d'idées. C'est une profusion. Les ventes veulent un chatbot, les opérations veulent un outil de prévision, la finance veut de la détection d'anomalies, et quelqu'un de haut placé veut quelque chose contenant le mot génératif parce qu'un concurrent en a annoncé un. La liste grandit plus vite que quiconque ne peut l'évaluer, et l'évaluation, quand elle a lieu, récompense souvent le sponsor le plus bruyant plutôt que l'idée qui ferait réellement avancer l'entreprise.
Ce n'est pas un problème technologique. La qualité des modèles a cessé d'être la contrainte déterminante pour la plupart des cas d'usage pratiques ; des modèles utilisables sont désormais un intrant courant, pas un facteur de différenciation. La contrainte réelle est organisationnelle : la capacité à trier un portefeuille de cas d'usage avec la même rigueur que pour les dépenses d'investissement, et la volonté d'abandonner les idées qui échouent au test. Peu d'organisations ont développé ce réflexe, et cela se voit au nombre de pilotes IA qui meurent discrètement dans un purgatoire de preuve de concept jamais remonté à la hiérarchie.
La nouveauté n'est pas un critère de sélection
La plus grande erreur dans la sélection des cas d'usage est de laisser la nouveauté tenir lieu de valeur. Un cas d'usage qui impressionne sur une diapositive de comité, résumer des documents juridiques, générer du contenu marketing, répondre aux clients avec un grand modèle de langage, ne mérite pas automatiquement d'être développé. La question qui compte est plus terre à terre : quelle valeur la résolution de ce problème crée-t-elle, à quelle fréquence ce problème se répète-t-il, et combien coûte-t-il aujourd'hui.
La densité de valeur, le bénéfice obtenu par unité d'effort, est un bien meilleur filtre que la sophistication technique. Une automatisation modeste qui supprime deux heures de rapprochement manuel à chaque clôture financière vaut souvent plus qu'un modèle ambitieux qui impressionne en démonstration mais touche un processus auquel personne ne consacre beaucoup de temps. Nous avons vu des organisations investir une année d'efforts d'ingénierie dans un cas d'usage IA phare qui, à y regarder de près, traitait une tâche consommant peut-être trois jours-homme par mois. L'effort aurait été rentabilisé plus vite avec une simple macro dans un tableur.
La contrainte déterminante sur la valeur de l'IA n'est plus le modèle. C'est la discipline de refuser le mauvais cas d'usage avant qu'il ne consomme une année de travail d'ingénierie.
La maturité des données compte plus que l'ambition
Le second filtre, celui que la plupart des comités de pilotage oublient, est de vérifier si les données sous-jacentes au cas d'usage sont réellement adaptées à la tâche. Non pas si des données existent quelque part, mais si elles sont étiquetées, à jour, cohérentes entre les systèmes et légalement exploitables pour l'usage prévu. Un cas d'usage peut être stratégiquement brillant et rester à douze mois de la viabilité simplement parce que les données sous-jacentes n'ont jamais été nettoyées, structurées ou gouvernées en vue de cette application.
C'est pourquoi nous demandons aux équipes de noter les cas d'usage sur la maturité des données avant de les noter sur la valeur métier. Une idée à forte valeur reposant sur des données inexploitables n'est pas annulée, elle est reséquencée ; quelqu'un doit prendre en charge le travail ingrat de préparation des données avant qu'un modèle ne s'en approche. Sauter cette étape, c'est comment les organisations se retrouvent avec un modèle qui performe magnifiquement en bac à sable et échoue discrètement dès qu'il rencontre les données de production.
- ·Noter chaque cas d'usage candidat sur sa densité de valeur, pas sur son intérêt technique
- ·Distinguer les données qui existent de celles qui sont exploitables pour l'usage précis visé
- ·Désigner un responsable clairement identifié pour la préparation des données avant tout travail de modélisation
- ·Exiger une date de décision d'arrêt pour chaque pilote, pas seulement une date de lancement
La politique du refus
Même avec un cadre solide, la partie la plus difficile du tri est sociale plutôt qu'analytique. Abandonner un cas d'usage signifie généralement dire à un sponsor, souvent haut placé, que son idée ne sera pas poursuivie. La plupart des processus de gouvernance sont conçus pour éviter cette conversation, ce qui explique pourquoi tant de pilotes à faible valeur survivent : personne ne veut être celui qui dit non au dirigeant dont c'était l'idée.
Les organisations qui réussissent cet exercice ont retiré la décision de toute personne individuelle pour la placer dans un cadre permanent appliqué de façon constante, de sorte qu'un refus découle des critères plutôt que d'un jugement personnel. Cela dépersonnalise la décision et la rend supportable pour les relations concernées. Cela signifie aussi que les mêmes règles s'appliquent lorsque l'idée favorite du directeur général est soumise à examen, ce qui est le véritable test de la crédibilité d'un processus de gouvernance.
Développer le réflexe, pas seulement le modèle
Rien de tout cela ne plaide contre l'ambition en matière d'IA. Cela plaide pour consacrer cette ambition aux idées les plus susceptibles de la mériter. Une approche de portefeuille, un petit nombre de cas d'usage bien choisis menés rapidement jusqu'en production, surpasse systématiquement une approche dispersée où vingt pilotes démarrent et deux seulement voient le jour.
Les organisations qui tirent une valeur réelle de l'IA aujourd'hui ne sont pas celles qui possèdent les modèles les plus avancés. Ce sont celles qui ont bâti un processus rigoureux pour choisir quoi construire, et qui ont eu le courage de s'y tenir.
Si votre programme d'IA compte plus de pilotes que de déploiements en production, le problème n'est probablement pas vos data scientists. Il s'agit plus probablement d'un processus de sélection qui n'a jamais appris à dire non.