Comment mesurer si un projet d'IA a réellement fonctionné
Un cadre pratique pour évaluer les projets d'IA par leurs résultats commerciaux — références, métriques réelles, coûts complets, et ce à surveiller après le lancement.
La mesure des projets d'IA : un guide pratique
La plupart des projets d'intelligence artificielle se terminent par une démonstration et des applaudissements. Peu d'entre eux se concluent par un chiffre. Six mois plus tard, personne ne peut dire si le système a permis de faire des économies, d'acquérir des clients ou simplement d'ajouter un nouvel outil au processus existant. Le problème n'est pas souvent la technologie elle-même. C'est que personne n'a défini à l'avance ce serait le succès avant le début du projet, donc le succès est devenu tout ce que le projet a produit.
Mesurer un projet d'IA n'est pas compliqué. Il faut simplement décider, avant de commencer, quel devrait être l'état des lieux pour l'entreprise si le projet fonctionne - puis vérifier.
Définir "le travail accompli" avant d'écrire le code
Un projet d'IA réussit lorsqu'il modifie un indicateur numérique sur lequel l'entreprise s'est déjà concentrée. Pas la précision, pas la qualité de la réponse, pas l'"adoption" abstraite. Un chiffre : les heures de travail manuel éliminées, les jours gagnés dans un processus, les taux d'erreur dans les factures, le coût par billet traité, les revenus par représentant.
Notez ce chiffre avant le début du projet, ainsi que l'objectif. "Le système devrait réduire le temps de préparation des devis de trois jours à un" est une affirmation vérifiable. "Le système améliorera l'efficacité" est une affirmation avec laquelle on peut être d'accord. Si l'équipe ne peut pas nommer le chiffre que le projet devrait atteindre, le projet n'est pas prêt à être financé.
Mesurer la base de référence en premier
On ne peut montrer d'amélioration par rapport à une base de référence que personne n'a enregistrée. Avant de mettre le système en ligne, passez une ou deux semaines à enregistrer comment se déroule le processus aujourd'hui : combien de temps prennent les tâches, à quelle fréquence elles échouent, quel est leur coût, qui les traite. C'est un travail peu glamour et c'est l'étape la plus souvent négligée lors de l'adoption de l'IA.
La base de référence n'a pas besoin d'être parfaite. Dix exemples chronométrés du processus actuel valent mieux que rien. Sans eux, toute conversation ultérieure sur la valeur devient un débat d'opinions.
Juger les résultats, pas la performance du modèle
Les équipes techniques signaleront des métriques techniques - précision, latence, scores de référence. Ces données sont importantes pour elles et ne devraient pas l'être pour vous. Un modèle peut être précis à 95% et quand même échouer en tant que projet si les 5% qu'il rate affectent vos clients les plus importants, ou si le personnel arrête d'utiliser le système discrètement en mars.
Les métriques qui méritent une attention au niveau de la direction se divisent en quatre groupes :
- Sortie : le travail est-il plus rapide, moins cher ou meilleur que la base de référence ?
- Adoption : quelle part du travail éligible passe effectivement par le système, et cette part augmente-t-elle ou diminue-t-elle ?
- Exceptions : un humain doit-il intervenir, corriger ou surcharger le système fréquemment - et ces cas deviennent-ils plus rares ?
- Confiance : les utilisateurs seraient-ils mécontents de perdre le système ?
Le chiffre d'adoption mérite une attention particulière. Un système utilisé pour 8% des cas éligibles n'a pas fonctionné, quelle que soit sa précision. La baisse de l'utilisation est le premier signal honnête qu'il y a un problème, et elle apparaît bien avant qu'un client ne se plaigne.
Calculer le coût total
Le coût de construction est la partie visible. Le véritable total inclut les éléments récurrents : les coûts d'abonnement et de calcul, le temps passé par le personnel à examiner les sorties, l'entretien lorsque un fournisseur modifie une API ou le processus sur lequel le système a été construit. Un projet qui économise vingt heures par semaine mais consomme dix en révision et entretien n'a qu'une véritable rentabilité moitié moins élevée que la tête de série.
Planifiez une revue à trois et six mois après le lancement et comparez le coût total de fonctionnement mesuré avec le gain réel. De nombreux projets qui semblaient marginaux au lancement sont clairement positifs un mois plus tard; certains qui ont fait une démonstration brillante sont clairement négatifs. Vous voulez savoir lequel vous avez avant qu'il ne soit trop tard pour l'arrêter ou le modifier.
Veiller à la dégradation
Un système d'IA n'est pas un pont ; il ne reste pas construit. Les données changent, l'entreprise change, le modèle derrière une API change sans préavis. Un système qui fonctionnait en janvier peut se dégrader tranquillement d'ici juillet, et comme les sorties semblent plausibles, personne ne s'en rend compte jusqu'à ce qu'un client le fasse.
La solution est légère : conservez un petit ensemble de cas connus avec des réponses correctes connues et faites-les passer régulièrement par le système. Si les résultats changent, vous découvrirez le problème grâce à vos propres contrôles plutôt que par le marché. Attribuez cette tâche à une personne nommée. La dégradation qui n'est la responsabilité de personne ne sera pas détectée.
Le test en une page
Si un projet d'IA a fonctionné, vous devriez être en mesure de l'énoncer en une page : la base de référence, l'objectif, le résultat mesuré, le coût total et la tendance depuis le lancement. Si cette page ne peut pas être écrite, la conclusion honnête n'est pas que le projet a échoué - c'est que personne ne sait, ce qui équivaut au même chose pour l'entreprise.
Cette discipline de mesure est plus lourde que la plupart des équipes s'y attendent, et elle en vaut exactement le coup - c'est ce qui distingue l'IA qui fait une bonne démonstration de celle qui rapporte. C'est aussi la partie de l'adoption qu'Hercules A intègre dès le début, donc la question "le projet a-t-il fonctionné ?" aura toujours une réponse numérique.