Point clé
N'étendez pas un projet pilote IA avant qu'un responsable nommé signe une hypothèse à cinq chiffres (base de référence, cible, adoption, coût complet et coût du retard) et une grille du premier jalon dont les seuils ont été fixés avant de voir les résultats.
Un projet pilote IA réussi prouve que quelque chose peut fonctionner. Il ne prouve pas que le déploiement va rapporter. Cet article s’adresse aux dirigeants et aux responsables de l’IA à qui l’on demande d’étendre un projet pilote. Il montre comment rédiger l’hypothèse économique que cette demande exige : cinq chiffres, un responsable et une grille pour le premier jalon.
Le projet pilote a fonctionné. La précision a dépassé la cible, les douze personnes qui l’ont utilisé disent qu’elles détesteraient le perdre, et le comité directeur a vu une belle démo. Il y a maintenant une demande sur la table pour le déployer dans tout le service, ou dans toute l’entreprise.
Cette demande mérite des questions plus dures que celles posées au projet pilote. Financer un projet pilote, c’est parier que quelque chose peut marcher. Financer le déploiement, c’est parier que ça va rapporter : à plein volume, avec des utilisateurs ordinaires, et avec un coût d’exploitation que personne n’a mesuré pendant le pilote. La plupart des résultats d’un pilote ne disent rien sur ce deuxième pari.
On a déjà écrit sur la façon de bâtir l’analyse de rentabilité d’un premier investissement en IA : choisir un cas d’usage, comparer les options de coût, modéliser la valeur sur trois ans. Cet article prend le relais. Aucune initiative IA ne devrait passer à l’échelle sans hypothèse économique, et cette hypothèse se résume à cinq chiffres et un nom.
Pourquoi les résultats d’un projet pilote IA ne tiennent-ils pas à grande échelle?
Parce qu’un pilote est conçu pour répondre à « est-ce que ça peut marcher? », et qu’il est monté de façon à rendre le oui plus probable. C’est correct pour un pilote. Ça devient un problème quand on se sert des mêmes résultats pour justifier un déploiement.
Le volume est sélectionné. Les équipes pilotes choisissent la tranche de travail la plus propre, souvent sans le vouloir. Les factures des trois plus gros fournisseurs. Les billets de soutien en anglais. Les réclamations sous un certain montant. Le plein volume inclut la longue traîne, et c’est là que vivent les taux d’erreur, la révision humaine et les cas limites.
Les utilisateurs sont des volontaires. Les premiers utilisateurs ont levé la main, ont eu l’attention de l’équipe de projet et une ligne directe avec ceux qui ont bâti l’outil. Les utilisateurs en production ne l’ont pas demandé, ont leurs propres échéances et contourneront un outil qui les ralentit une seule fois.
Le coût d’exploitation est caché. L’inférence roulait souvent sur des crédits du fournisseur. Le scientifique des données qui a bâti le modèle faisait la révision humaine. La surveillance, c’était quelqu’un qui jetait un œil à un carnet. Rien de tout ça n’apparaît comme poste budgétaire, alors le coût unitaire du pilote semble presque nul.
Certains coûts croissent avec le volume, d’autres plus vite. Le coût d’inférence suit à peu près le volume de requêtes. La révision humaine suit le volume multiplié par le taux d’exceptions, et ce taux augmente généralement à mesure qu’on avance dans le travail plus désordonné. La charge de soutien croît avec le nombre d’utilisateurs, pas avec le nombre de transactions.
Les indicateurs mesurent le modèle, pas l’entreprise. La précision, le rappel et la satisfaction des utilisateurs sont des signaux d’ingénierie utiles. Aucun n’est le coût par dossier, le temps de cycle ou le chiffre de revenus dont un chef des finances doit répondre. On aborde cet écart dans mesurer le succès des fonctionnalités IA.
Les programmes des AI & Data Summit d’IDC au Canada cette année placent la valeur d’affaires et le rendement du capital investi (RCI) parmi les sujets clés, et réclament « clear KPI frameworks, strong business cases, and scalable use cases tied to financial value ». Pour y arriver, il faut surtout écrire quelques chiffres précis avant que le déploiement commence, et bâtir le système pour qu’on puisse les vérifier ensuite.
Qu’est-ce qu’une hypothèse économique pour une initiative IA?
C’est un énoncé unique qui pourrait se révéler faux. Il nomme l’adoption, l’indicateur opérationnel, la valeur, le coût complet et la personne imputable, et il a cette forme :
Si [adoption] du [travail] admissible passe par le système d’ici [date], alors [indicateur opérationnel] passe de [base de référence] à [cible], ce qui vaut [$ par mois], pour un [coût complet]. [Responsable] est imputable du résultat, et on le vérifiera au [premier jalon].
Deux choses le rendent utile. Il est assez précis pour que quelqu’un puisse se tromper. Et il nomme la personne à qui on posera la question dans deux trimestres, ce qui change le soin que tout le monde met à le remplir.
Quels cinq chiffres faut-il pour étendre une initiative IA?
La base de référence, la cible, l’adoption, le coût complet et le coût du retard. Chacun a une source et une façon classique de se tromper.
| # | Chiffre | Ce que c’est | D’où il vient | Erreur fréquente |
|---|---|---|---|---|
| 1 | Base de référence | L’indicateur opérationnel que le système fait bouger, mesuré aujourd’hui, en unités et en dollars | Systèmes de référence : PGI, billetterie, CRM, feuilles de temps. Un échantillon de deux semaines si rien d’autre n’existe. | Utiliser les chiffres de l’équipe pilote. C’étaient déjà les plus performants. |
| 2 | Cible | Où cet indicateur atterrit sur tout le volume admissible, et pour quand | Les résultats du pilote, réduits pour tenir compte du travail que le pilote n’a pas vu | Projeter la meilleure semaine du pilote sur toute la population |
| 3 | Adoption | La part du travail admissible qui passe par le système à chaque jalon | Un plan de montée en charge convenu avec le responsable : mois 2, mois 4, mois 6 | Supposer 100 %, ou supposer que l’adoption se fera toute seule |
| 4 | Coût complet | Coût ponctuel pour passer à l’échelle, plus coût mensuel d’exploitation | Estimation de l’intégration, prix de l’inférence au volume prévu, personnel de révision, surveillance, soutien | Compter la construction et oublier l’exploitation |
| 5 | Coût du retard | La valeur nette perdue chaque mois où le système à l’échelle n’est pas en service | Dérivé des chiffres 1 à 4 | L’omettre, pour que chaque révision et chaque étape d’approvisionnement semble gratuite |
Puis il y a le responsable : une personne dont l’état des résultats ou l’indicateur opérationnel bouge. Pas le responsable de l’IA ni le fournisseur, et jamais un comité directeur. Si personne n’accepte de mettre son nom à côté de la cible, l’initiative n’est pas prête à passer à l’échelle, peu importe ce que le pilote a montré.
Pourquoi l’adoption a-t-elle besoin de son propre plan?
Parce que c’est l’adoption qui fait le plus souvent échouer un passage à l’échelle, et c’est le chiffre qu’on écrit le moins souvent. Un modèle qui fait gagner dix minutes par dossier ne fait rien gagner sur les dossiers qui ne lui parviennent jamais.
Les plans d’adoption qui tiennent la route ont trois parties : quelles équipes embarquent à quel jalon, ce qui change dans leur façon de travailler (l’outil remplace une étape au lieu d’ajouter un onglet), et qui, dans chaque équipe, est responsable de l’utilisation. Le responsable approuve la montée en charge. S’il refuse de s’engager sur une montée, vous avez votre réponse sur l’adoption.
Que doit inclure le coût complet?
Tout ce qui roule, pas seulement la construction. Pour le coût ponctuel du passage à l’échelle, incluez l’intégration aux systèmes de référence, un jeu d’évaluation qui représente le plein volume plutôt que la tranche du pilote, l’examen de sécurité et de confidentialité, et la formation des équipes qui embarquent.
Pour le coût mensuel d’exploitation, incluez l’inférence au volume prévu (avec une marge, puisque les requêtes ont tendance à grossir), la révision humaine des exceptions et des résultats peu fiables, la surveillance et la garde, ainsi que le temps d’ingénierie pour maintenir les requêtes, les modèles et les intégrations à mesure que les systèmes en amont changent. Pour en savoir plus sur la surveillance en production, voyez l’observabilité des agents IA.
Comment calculer le coût du retard?
C’est de l’arithmétique, pas de la rhétorique. Une fois les quatre premiers chiffres en main :
valeur brute mensuelle = volume admissible × adoption × (coût unitaire de base − coût unitaire cible)
valeur nette mensuelle = valeur brute mensuelle − coût mensuel d'exploitation
coût du retard = valeur nette mensuelle (au niveau d'adoption qu'on aurait atteint)
mois de récupération = coût ponctuel du passage à l'échelle ÷ valeur nette mensuelleC’est un chiffre approximatif. Son rôle est de mettre un prix visible sur un cycle d’approvisionnement de quatre mois ou une demande d’accès aux données qui traîne.
À quoi ressemble une hypothèse économique pour un vrai flux de travail?
En voici une pour les exceptions de factures, avec des chiffres fournis à titre d’illustration. La structure s’applique à la plupart des projets d’automatisation de processus.
Un distributeur de taille moyenne a mené un projet pilote de 10 semaines sur les exceptions de factures fournisseurs : les factures qui échouent au rapprochement automatique à trois volets avec le bon de commande et le bon de réception. Le système lit la facture, va chercher le bon de commande et la réception, propose une résolution et rédige la note au fournisseur. Un commis aux comptes fournisseurs l’approuve ou la corrige.
Le pilote traitait environ 300 exceptions par mois pour une seule équipe des comptes fournisseurs. Les résolutions proposées étaient acceptées sans modification 91 % du temps. L’équipe l’aimait. La demande : le déployer dans tous les comptes fournisseurs.
1. Base de référence. L’entreprise traite 18 000 factures par mois, et 22 % échouent au rapprochement : 3 960 exceptions. Le temps de traitement moyen est de 25 minutes, à un coût complet de 48 $ l’heure, donc 20 $ par exception et environ 79 200 $ par mois.
2. Cible. Le temps de traitement tombe à 10 minutes pour les exceptions qui passent par le système : 8 $ chacune, une économie de 12 $. Le pilote affichait une moyenne de 8 minutes, mais il excluait les factures de transport et multidevises, alors la cible est volontairement plus haute que le résultat du pilote.
3. Adoption. 25 % des exceptions acheminées au mois 2, 50 % au mois 4, 70 % au mois 6. Les autres 30 % (formats de fournisseurs inhabituels, litiges) restent manuelles pour l’instant.
4. Coût complet. Un coût ponctuel de 180 000 $ pour passer à l’échelle : intégration au PGI au-delà de l’export en lecture seule du pilote, jeu d’évaluation couvrant tous les types de fournisseurs, examen de sécurité et formation. Un coût mensuel d’exploitation de 10 000 $ : environ 2 500 $ d’inférence, environ 4 000 $ pour une spécialiste principale des comptes fournisseurs qui révise la qualité à mi-temps, et environ 3 500 $ pour la surveillance et l’entretien.
5. Coût du retard. À 70 % d’adoption, 2 772 exceptions par mois × 12 $ = 33 264 $ bruts. Moins 10 000 $ d’exploitation, ça donne environ 23 000 $ nets par mois. Chaque mois de retard après le mois 6 coûte à peu près ce montant. Les 180 000 $ sont récupérés environ huit mois après l’adoption complète, un peu plus en comptant la montée en charge.
Responsable : le contrôleur de l’entreprise, qui est responsable des coûts des comptes fournisseurs et des délais de fermeture.
Sous forme d’hypothèse : Si 70 % des exceptions de factures passent par le système d’ici le mois 6, le coût de traitement de ces exceptions passe de 20 $ à 8 $, ce qui vaut environ 33 000 $ bruts par mois, pour 180 000 $ de passage à l’échelle et 10 000 $ par mois d’exploitation. Le contrôleur est responsable du résultat, vérifié au jalon du mois 2.
Comment évaluer le premier jalon d’un déploiement IA?
Avec une grille dont les seuils sont convenus avant le début des travaux, pour que la décision au jalon soit mécanique plutôt que politique. « Phase 2 terminée », ce n’est pas un jalon. Trois issues le sont : continuer, ajuster ou arrêter.
Pour l’exemple ci-dessus, au mois 2 :
| Mesure | Continuer le déploiement | Ajuster et revérifier dans 4 semaines | Arrêter ou redéfinir |
|---|---|---|---|
| Adoption (part des exceptions acheminées) | ≥ 25 % | 15 à 25 % | < 15 % |
| Temps de traitement des exceptions acheminées | ≤ 11 min | 11 à 15 min | > 15 min |
| Coût d’exploitation par exception acheminée | ≤ 4,50 $ | 4,50 $ à 6,00 $ | > 6,00 $ |
| Acceptées sans modification | ≥ 85 % | 75 à 85 % | < 75 % |
| Revue du responsable tenue, décision consignée | Oui | s.o. | Aucune revue du responsable dans les deux semaines suivant le jalon |
Écrivez ce que chaque colonne déclenche. « Ajuster » pourrait vouloir dire réduire les types de factures acheminées ou ajouter une étape de révision. « Arrêter » pourrait vouloir dire revenir à la portée du pilote le temps de régler un problème de données. Personne ne devrait avoir à inventer les critères après avoir vu les résultats.
Que doit bâtir l’ingénierie pour qu’on puisse vérifier les chiffres?
De l’instrumentation, en place avant le passage à l’échelle. La plupart des pilotes n’en ont pas, et c’est une des raisons pour lesquelles tant de déploiements ne peuvent pas répondre à « est-ce que ça a marché? ». Voici les cinq éléments qu’on met en place en premier :
- L’attribution des coûts par requête. Étiquetez chaque appel au modèle avec le flux, l’équipe et le numéro de dossier, pour que le coût d’exploitation unitaire soit une requête et non une estimation.
- La journalisation des résultats. Pour chaque dossier : ce que le système a proposé, ce que la personne a fait (accepté, modifié, rejeté) et le temps de traitement. Ce sont aussi vos données étiquetées pour améliorer le système.
- Un groupe de comparaison. Pendant la montée en charge, les équipes qui n’utilisent pas encore le système sont votre base de référence. Comparez du travail équivalent entre les deux groupes plutôt que de comparer avec l’an dernier.
- Un jeu d’évaluation fidèle à la production. Rebâtissez-le à partir d’échantillons du plein volume, y compris les cas exclus du pilote. La précision sur la tranche du pilote en dit peu sur la longue traîne.
- Un indicateur que le responsable suit déjà. Mettez la grille dans le rapport que le contrôleur (ou le responsable, quel qu’il soit) consulte déjà. Un tableau de bord IA à part est consulté pendant deux semaines.
Rien de tout ça n’est exotique. Notre article sur le passage du projet pilote à la production couvre plus en détail le volet ingénierie de cette transition.
Où une hypothèse économique IA casse-t-elle habituellement?
Sur l’un de trois chiffres : l’adoption, le coût complet ou la base de référence. C’est l’adoption qui rate le plus souvent.
L’adoption. La solution est rarement plus de formation. C’est généralement le flux de travail : l’outil ajoute une étape au lieu d’en retirer une, ou il vit en dehors du système où le travail se fait.
Le coût complet. Il rate ensuite, surtout à cause de la révision humaine. À mesure que le volume s’étend aux cas plus désordonnés, la part des résultats peu fiables augmente et le temps de révision croît plus vite que prévu. Réduire la portée au travail que le système gère bien est souvent la bonne décision.
La base de référence. Parfois, elle était fausse. L’équipe était plus rapide que l’échantillon le laissait croire, ou le processus a changé pendant le pilote. Ce n’est pas un échec de l’initiative, mais ça change la valeur, et il faut réécrire l’hypothèse plutôt que la défendre.
Une hypothèse qui échoue au premier jalon a fait son travail. Vous l’avez appris au prix d’une montée en charge, pas d’un déploiement complet.
Questions fréquentes
Comment savoir si un projet pilote IA est prêt à passer à l’échelle?
Quand un responsable nommé a signé une hypothèse avec une base de référence mesurée, une cible réduite pour tenir compte du travail que le pilote n’a pas vu, un plan d’adoption, un coût d’exploitation complet et des seuils de jalon convenus. Une bonne précision en pilote ne suffit pas.
Quels coûts les projets pilotes IA oublient-ils habituellement?
Les coûts d’exploitation : l’inférence à plein volume, la révision humaine des exceptions et des résultats peu fiables, la surveillance et la garde, et l’entretien continu des requêtes, des modèles et des intégrations. Les pilotes les cachent souvent derrière des crédits du fournisseur et le temps de la personne qui a bâti l’outil.
Que faire si un déploiement IA rate son premier jalon?
Suivre ce que la grille prévoyait d’avance. En général, ça veut dire réduire la portée, corriger le flux pour que l’outil retire une étape, ou réécrire l’hypothèse autour d’une base de référence corrigée plutôt que de défendre l’ancienne.
Une de vos initiatives IA attend-elle une décision de passage à l’échelle?
Envoyez-nous une courte description : ce qu’elle fait, qui l’utilise aujourd’hui et ce qu’elle est censée améliorer. On vous renverra les cinq chiffres dont son dossier a besoin, en indiquant ceux que vous avez probablement déjà, et une ébauche de grille du premier jalon à présenter à votre chef des finances. Si les chiffres tiennent, nos ingénieurs s’intègrent à votre équipe et bâtissent la version de production dans votre pile, avec l’instrumentation pour le prouver. Envoyez-nous une initiative.