Une revue utile du portefeuille IA devrait imposer à chaque pilote l’une de ces trois décisions : le déployer à plus grande échelle, corriger une incertitude bien définie ou l’arrêter. Tout projet dit « en pause » a besoin d’une dépendance identifiée, d’un responsable et d’une date de décision. Sans cela, la pause n’est qu’une décision d’arrêt que personne ne veut prendre.
C’est ce que j’appelle une liste d’arrêt. Il ne s’agit ni d’un quota de projets ratés ni d’une arme contre les personnes qui les ont proposés. C’est un registre visible des travaux pour lesquels le prochain euro investi n’a plus de justification défendable. Bien utilisée, cette liste rend du capital, des capacités techniques rares et du budget de risque à de meilleures opportunités.
Cette méthode boucle la démarche entre la planification d’un budget IA, la mesure de l’économie complète de l’IA et l’action lorsque les faits changent. Un portefeuille qui sait lancer des expériences mais ne sait pas les arrêter n’apprend pas. Il accumule des obligations.
Continuer est aussi une décision
Les pilotes IA sont faciles à approuver parce que chacun paraît modeste. Le coût du portefeuille se cache dans le total : consommation des modèles et plateformes, travail sur les données, revue de sécurité, intégration, évaluation, support et attention de personnes qui pourraient résoudre un autre problème.
La revue doit donc comparer la prochaine dépense au meilleur autre usage de ces ressources. L’argent déjà dépensé peut expliquer ce que l’organisation a appris, mais il ne renforce pas la prochaine demande de financement. Le Green Book 2026 du HM Treasury établit la même distinction : les coûts irrécupérables ne doivent pas guider la prochaine décision, alors que le coût d’opportunité lié à la poursuite de l’utilisation des ressources compte toujours.
Il ne devrait pas exister de délai universel de six mois. Un assistant documentaire et un workflow clinique assisté par IA n’ont pas les mêmes besoins de preuve et d’assurance. La discipline essentielle consiste à fixer le calendrier avant de commencer, à l’adapter à l’incertitude testée et à empêcher l’équipe de déplacer la ligne d’arrivée après avoir vu le résultat.
Écrire le contrat de revue avant le pilote
Chaque pilote devrait entrer dans le portefeuille avec un court contrat de revue. Si l’équipe ne peut pas le remplir en langage clair, elle n’est probablement pas encore prête à dépenser.
| Élément de revue | Ce que le portefeuille doit savoir |
|---|---|
| Résultat métier | Qu’est-ce qui change pour un client, un collaborateur, une opération, un revenu ou une exposition au risque ? |
| Situation de départ | Comment le travail fonctionne-t-il aujourd’hui sans le système IA proposé ? |
| Preuve attendue | Quel résultat justifierait l’étape suivante, et comment sera-t-il mesuré ? |
| Coût complet | Que demanderont le développement, l’exploitation, la revue, le contrôle et le support ? |
| Limite de risque | Quel échec ou risque résiduel rendrait la poursuite inacceptable ? |
| Sponsor | Qui porte le résultat métier et peut prendre la décision d’arrêt ? |
| Date de décision | Quand les faits seront-ils examinés plutôt que simplement présentés ? |
| Plan de sortie | Comment les accès, données, intégrations, fournisseurs et infrastructures seront-ils retirés ? |
Cela ne transforme pas l’innovation en concours administratif. Le contrat doit être proportionné au coût, à la complexité et aux conséquences. Il sert à empêcher le portefeuille d’inventer ses critères de réussite après que l’expérience a déjà produit un résultat ambigu.
Le NIST AI Risk Management Framework soutient cette vision du cycle de vie. Sa fonction Manage appelle à décider si un système IA atteint l’objectif prévu et si son développement ou son déploiement doivent se poursuivre. Elle demande aussi des mécanismes et des responsabilités attribuées pour désengager ou désactiver les systèmes dont les performances ou les résultats contredisent l’usage prévu.
S’en tenir à trois résultats réels
Au moment de la revue, choisissez l’un de ces trois résultats et consignez la raison.
- Déployer à plus grande échelle lorsque le pilote a produit des preuves utiles, que le coût d’exploitation est crédible, que le risque reste dans la tolérance et qu’un responsable est prêt à l’exploiter comme un produit pris en charge.
- Réparer lorsqu’une incertitude importante peut encore être testée par une modification précise et limitée dans le temps. Réparer ne donne pas la permission de recommencer tout le pilote avec une nouvelle histoire.
- Arrêter lorsque le besoin métier a changé, que les preuves n’atteignent pas le seuil, que l’économie ne tient plus, que le risque ne peut être ramené dans la tolérance, que le sponsor a disparu ou qu’une solution plus simple sans IA est préférable.
La catégorie « réparer » est celle où les portefeuilles perdent souvent leur discipline. Donnez-lui une hypothèse, un responsable, une limite budgétaire et une nouvelle date de revue. Si l’équipe revient avec un autre cas d’usage, d’autres utilisateurs et d’autres critères de réussite, c’est une nouvelle proposition, pas la preuve que l’ancienne a réussi.
La préparation à la production mérite aussi une barre plus haute qu’une démonstration convaincante. Le modèle minimal viable de gouvernance IA apporte des niveaux de risque et des jalons de preuve, tandis que l’exploitation de l’IA au jour deux rend visibles la responsabilité, la supervision, la réponse aux incidents et la reprise. Si ces obligations rendent l’économie peu attractive, le portefeuille a appris quelque chose d’important avant de déployer la responsabilité à grande échelle.
Compter les enseignements sans inventer de ROI
Un pilote arrêté n’a pas besoin d’un retour sur investissement fictif pour avoir de la valeur. Présentez honnêtement ce qu’il a appris :
- les dépenses futures évitées après la décision ;
- les capacités rendues à l’ingénierie, la sécurité, la donnée et aux métiers ;
- un risque ou une dépendance supprimés ;
- une hypothèse réfutée ;
- des données d’évaluation, travaux d’intégration ou modèles de contrôle réutilisables ; et
- une meilleure question de sélection pour la prochaine proposition.
Séparez les coûts futurs évités de l’argent déjà dépensé, et ne comptez pas le temps libéré comme une économie si l’organisation ne peut pas montrer où cette capacité a été redéployée. Le but est de conserver une décision qui améliore la prochaine allocation, pas de produire une astuce arithmétique qui donne l’apparence du succès à chaque expérience.
La liste d’arrêt doit aussi préserver le motif de la décision. Avec le temps, les causes récurrentes peuvent révéler des problèmes à l’échelle du portefeuille : cas d’usage sans référence de départ, responsables métier absents, données non prêtes, contrôles ajoutés trop tard ou économie unitaire qui échoue face à des exigences de qualité réalistes. Ces éléments sont plus utiles qu’un tableau de bord indiquant seulement combien de pilotes restent actifs.
Rendre la vérité facile à dire
La peur est un mauvais modèle opérationnel. Si l’arrêt d’un pilote devient une faute imputée à l’équipe, les personnes masqueront les signaux faibles, réduiront le périmètre des mesures et demanderont un cycle de plus. La gouvernance doit séparer la qualité de l’expérience de la décision de poursuivre l’investissement.
Le sponsor métier porte le résultat. L’équipe technique garantit l’intégrité des preuves. L’instance de portefeuille assume l’arbitrage pour l’entreprise. Cette répartition évite de demander à une équipe projet de défendre sa propre existence et empêche une division de protéger une initiative locale au détriment de l’entreprise entière.
Les dirigeants donnent le ton en demandant : « Qu’avons-nous appris, et où cette capacité devrait-elle aller maintenant ? » C’est une question plus difficile et plus utile que : « Qui a échoué ? »
Conduire la prochaine revue autrement
Commencez par tous les pilotes IA actifs, pas seulement ceux qui demandent de nouveaux fonds. Donnez à chaque sponsor une page présentant le contrat de revue, les preuves réelles, l’incertitude restante, le coût complet de l’étape suivante et le résultat recommandé.
Prenez ensuite en réunion la décision de déployer, réparer ou arrêter. Publiez en interne la liste d’arrêt avec le motif, la capacité libérée, les enseignements réutilisables et le responsable du retrait. Enfin, vérifiez que les identifiants, copies de données, engagements fournisseurs, intégrations et infrastructures ont réellement été retirés. Une décision dans une présentation n’est pas un démantèlement.
L’objectif n’est pas d’arrêter davantage de projets IA. Il est de veiller à ce que chaque projet continue parce que les preuves actuelles le justifient, pas parce que l’arrêter met mal à l’aise.
