Cet article présente des considérations analytiques construites sur la base exclusive d'informations rendues publiques par les institutions concernées.
Un modèle peut être techniquement irréprochable et ne rien changer du tout.
Pour révolutionner un secteur, il ne suffit pas d'être bon techniquement.
Le problème n'est pas là où on le cherche
Prenons deux cas publics, aux temporalités et périmètres d'intervention opposés, tout en étant majeurs sur la conduite de l'action publique.
Le premier : un algorithme de détection des arrêts cardio-respiratoires sur les lignes d'urgence. Entraîné sur plus de dix ans d'appels, il est capable d'identifier en moins de quinze secondes les signes caractéristiques d'un arrêt cardio-respiratoire (bruit ambiant, respiration, vocabulaire).
Pour les plus geeks, c'est un recoupement d'analyse du son et du NLP appliqué à des milliers d'appels, avec un apprentissage par le recoupement desdits enregistrements avec les rapports post-intervention des pompiers.
L'objectif déclaré : permettre à l'opérateur de déclencher un massage cardiaque guidé par téléphone en moins d'une minute, contre deux minutes trente en moyenne sans assistance d'IA. Chaque minute gagnée représente dix points de probabilité de survie supplémentaires, soit environ 400 vies par an sur le périmètre de l'Ile-de-France.
Le modèle fonctionne et est pertinent.
Le second : un outil de recherche indexée (RAG) pour l'instruction de dossiers d'évaluation environnementale. Quatre mille dossiers traités par an, sous délai contraint, par des équipes en effectifs limités. L'outil identifie les enjeux environnementaux, détecte les contradictions réglementaires, propose des éléments de rédaction d'avis. Le gain de temps mesuré : dix à vingt pour cent.
L'outil fonctionne.
Dans les deux cas, la question technique est résolue. Ce qui reste ouverte, c'est une autre question, liée aux organisations et à leurs pratiques de décision.
La vraie question
Dans le cas de la détection d'ACR, l'algorithme score, c'est à dire qu'il attribue une probabilité. Autrement dit, il ne décide pas. L'humain décide.
Ce qui change avec l'outil, c'est la condition dans laquelle l'opérateur prend sa décision : plus vite, sur la base d'une pré-analyse qu'il n'a pas eu le temps d'effectuer. La valeur du modèle dépend entièrement de ce que l'opérateur fait de ce signal. Elle dépend de sa formation, de la clarté du protocole, de sa confiance dans le système, et de sa capacité à agir différemment qu'il ne l'aurait fait sans l'outil.
Dans le cas de LIRIAe, le critère de succès retenu par les porteurs du projet n'est pas le gain de temps. C'est « l'appréciation des auditeurs ». Un outil qui réduit le temps de traitement de vingt pour cent mais que personne n'utilise après le pilote ne change rien. La mesure d'impact est organisationnelle avant d'être technique.
C'est le même problème dans les deux cas : un modèle produit un signal. Une organisation décide ce qu'elle en fait. Si elle décide de l'acheter, quand il s'agit d'une start-up.
Ce que ça implique si vous construisez un modèle
Si vous développez un produit algorithmique, vous connaissez déjà cette tension. Vos prospects institutionnels valident le POC, louent les performances, et n'achètent pas. Ou achètent et n'utilisent pas. Ou utilisent pendant six mois et demandent un désabonnement.
Ce n'est pas un problème de produit. C'est un problème de chaîne de valeur.
Votre modèle produit un output. Cet output doit modifier un comportement. Ce comportement doit s'inscrire dans un processus. Ce processus doit être accepté par les équipes qui l'utilisent. Ces équipes doivent avoir été formées, accepter le nouveau deal d'être possible déclassés, et les responsables hiérarchiques doivent avoir redéfini ce qu'ils attendent d'elles.
Cette prise de décision, au niveau hiérarchique, se complexifie par les mécanismes à l'œuvre : rationalité économique pure ? Décision politique ? Réorientation stratégique de l'entreprise avec évolution de la chaîne de création de valeur ?
C'est cinq maillons entre votre modèle et l'impact réel. Si l'un d'eux manque, le modèle ne change rien, quelle que soit sa performance technique.
Il existe un troisième cas public qui illustre ce point par un angle différent.
Un outil d'évaluation automatisée des systèmes RAG, conçu précisément parce que le problème des déploiements RAG n'est pas la performance initiale, c'est la régression de qualité entre deux versions. Un modèle validé en production peut se dégrader silencieusement à chaque mise à jour du corpus ou du LLM sous-jacent. La question n'est pas « est-ce que ça marche » mais « est-ce que ça continue à marcher, et comment le sait-on ». C'est une question organisationnelle déguisée en question technique.
Or, les organisations prennent la décision d'adopter votre outil parce que :
- Il accélère l'atteinte de l'objectif cible de l'organisation
- Il ne contrarie pas les agendas non assumé des parties-prenantes de l'organisation
- Il n'expose pas l'organisation à une responsabilité excessive au regard du gain de productivité.
Ce que les organisations qui réussissent font différemment
Elles posent la question de l'organisation avant la question du modèle. Pas « quelle performance peut-on atteindre » mais « quelle décision voulons-nous améliorer, qui la prend, dans quel contexte, et qu'est-ce qui doit changer dans l'organisation pour que le signal de l'IA modifie réellement cette décision ».
Ce n'est pas une question que les équipes techniques peuvent résoudre seules. Ce n'est pas non plus une question que les décideurs peuvent résoudre sans comprendre ce que le modèle peut et ne peut pas faire.
C'est l'espace entre les deux. C'est là que les projets gagnent ou perdent.