Un POC terminé, un service toujours actif
Un proof of concept d'intelligence artificielle se conclut rarement par un arrêt net. L'expérimentation s'achève sur une démonstration, une conclusion partagée ou un budget épuisé, mais l'endpoint continue de tourner. Et tant qu'il tourne, il facture.
Ce décalage est facile à manquer. Personne ne reçoit d'alerte le jour où le prototype perd son sens. Le service reste actif par inertie, et son coût se fond dans une ligne de facturation plus large, sans que quiconque ait explicitement décidé de le maintenir en vie.
Le vide de responsabilité entre expérimentation et production
Entre l'expérimentation et la production, un vide de responsabilité peut apparaître. Pendant la phase de test, une équipe est mobilisée, un sponsor suit le sujet, des questions sont posées régulièrement. Une fois le POC terminé, l'attention se déplace vers d'autres priorités. Personne ne possède plus le budget, le service reste actif, et sa valeur n'est plus mesurée.
Le problème n'est pas d'abord technique. Il est organisationnel : la fin d'un POC n'est pas un événement automatique, et rien n'arrête un service par défaut. Sans décision explicite, le statu quo s'installe, avec un coût récurrent qui n'est plus rattaché à un objectif.
Trois issues explicites plutôt qu'un statu quo
Une approche possible consiste à fixer une date de revue dès le démarrage du prototype, avec trois issues explicites : industrialiser la solution, la prolonger avec un budget et des critères clairs, ou l'arrêter et supprimer les ressources.
Chacune de ces issues a ses implications. Industrialiser suppose un porteur, un cadre de production et une valeur identifiée. Prolonger suppose de définir à l'avance ce qui justifierait une nouvelle période : quels usages, quels résultats attendus, quel coût acceptable. Arrêter suppose d'assumer une décision souvent inconfortable, mais qui évite de financer indéfiniment un service sans usage.
Le point clé est que l'absence de décision n'est pas neutre : elle équivaut à prolonger sans critère. Fixer la date de revue au début, plutôt qu'à la fin, évite que la question soit repoussée au moment où l'attention s'est déjà dissipée.
La passation : code, données, propriétaire, coût récurrent, alertes, arrêt
Une passation structurée devrait couvrir plusieurs éléments : le code, les données, le propriétaire désigné, le coût récurrent, les alertes et la procédure d'arrêt.
Le code et les données déterminent ce qui peut être repris ou archivé. Le propriétaire répond à la question « qui décide ? ». Le coût récurrent, souvent exprimé en dépense mensuelle ou annuelle, rend visible ce que le maintien du service engage. Les alertes permettent de détecter une dérive, par exemple une consommation qui augmente sans usage associé. La procédure d'arrêt évite les ressources orphelines, ces composants qui continuent de fonctionner parce que personne ne sait comment les éteindre proprement.
Sans ces éléments, la décision de continuer ou d'arrêter reste difficile à prendre, faute d'information partagée.
Le rôle du FinOps : rendre le coût visible, pas trancher seul
Le FinOps ne devrait pas décider seul si un produit mérite de continuer. Son apport consiste à rendre visible le coût du temps supplémentaire, afin que les bonnes personnes puissent décider en connaissance de cause.
Cette distinction est importante. Le coût est une donnée, pas un verdict. Un service peut coûter cher et créer beaucoup de valeur, ou coûter peu et ne servir à personne. La décision de poursuivre relève d'une appréciation produit et métier, éclairée par les chiffres. Confondre les deux rôles conduit soit à des arbitrages purement budgétaires, soit à une prolongation sans regard sur les ressources engagées.
Qui doit arrêter un POC qui n'atteint jamais la production ?
La question reste ouverte : qui est responsable de l'arrêt d'un POC d'IA qui n'atteint jamais la production ? Selon les organisations, la réponse peut varier : le propriétaire désigné lors de la passation, le sponsor qui a porté l'expérimentation, ou une instance produit qui arbitre les priorités.
L'essentiel est que la réponse soit connue avant la fin du POC, et non découverte après coup. Une gouvernance claire, une date de revue et une passation documentée transforment une inertie coûteuse en choix assumé. La question à se poser n'est pas seulement « combien cela coûte ? », mais « qui décide, et sur quels critères ? ».
Le post à l’origine de cette analyse
Article développé à partir du post LinkedIn. Les liens ci-dessous sont ceux du post d’origine ; leur présence ne constitue pas une vérification indépendante.
LinkedIn ↗