Azure FinOps pour municipalités : −30 % en 6 mois, méthode et pièges

Pourquoi les organisations québécoises explosent leur budget Azure

Depuis 2022, les municipalités, MRC, organismes parapublics et grandes entreprises québécoises ont massivement migré vers Azure. La promesse : flexibilité, scalabilité, dernière génération de services. La réalité, 24 mois plus tard : une facture multipliée par 2 ou 3 par rapport à l'estimation initiale.

Le coupable n'est jamais Azure lui-même. Ce sont quatre mécaniques humaines et organisationnelles qui se cumulent : machines surdimensionnées par prudence lors de la migration, environnements de test laissés actifs 24/7, absence de tagging qui rend impossible toute attribution des coûts, et pas de gouvernance sur la création de nouvelles ressources.

Le bon réflexe n'est pas de couper sauvagement, c'est d'instaurer un cycle FinOps structuré. Voici la méthode que nous appliquons systématiquement.

Les 5 leviers FinOps prioritaires

Tous les leviers ne donnent pas le même gain. Voici l'ordre d'impact décroissant, basé sur 12 mandats FinOps menés en 2024-2025 :

• Reserved Instances et Savings Plans (gain typique : 25 à 55 % sur le compute) - engagement 1 ou 3 ans sur des charges stables.
• Rightsizing des VMs et des bases de données (gain typique : 15 à 35 %) - la majorité des ressources sont surdimensionnées de 30 à 60 % vs l'usage réel.
• Extinction automatique des environnements dev/test hors heures ouvrables (gain typique : 60 à 70 % sur ces environnements).
• Storage tiering (Hot → Cool → Archive) pour les données peu accédées (gain typique : 40 à 80 % sur le stockage).
• Suppression des ressources orphelines : disques non attachés, IP publiques inutilisées, snapshots oubliés (gain ponctuel souvent significatif).

Étape 1 - Visibilité et tagging

Aucune optimisation n'est possible sans visibilité. La première étape, toujours, est de mettre en place un tagging structuré (environment, application, owner, cost-center, criticality) appliqué à 100 % des ressources existantes.

Microsoft Azure Policy permet de bloquer la création de nouvelles ressources sans tags obligatoires. Sans cette barrière, le tagging dérive en 60 jours. Nous combinons cela avec Cost Management + Billing pour produire des tableaux de bord par application et par direction.

Pour une municipalité, cela permet de répondre clairement à la question politique « combien coûte le service citoyens en ligne ? » - chiffre qu'aucune DSI n'arrivait à produire avant.

Étape 2 - Rightsizing et reservations

Azure Advisor et Azure Cost Management produisent des recommandations de rightsizing. Le piège : les appliquer en masse sans validation business.

Notre méthode : analyser 30 jours d'utilisation CPU/RAM/IOPS, identifier les ressources sur-dimensionnées (utilisation < 40 % en P95), proposer un nouveau sizing, valider avec le métier, programmer la bascule lors d'une fenêtre de maintenance.

Pour les reservations, l'analyse porte sur la stabilité de la charge. Une VM Production qui tourne 24/7 depuis 6 mois est un candidat évident pour une Reserved Instance 3 ans. Une VM batch qui ne tourne que 4 heures par nuit ne l'est pas - c'est plutôt un candidat à la spot pricing.

Étape 3 - Gouvernance et politiques

Une fois les gains capturés, il faut empêcher le retour à l'état antérieur. La gouvernance se traduit par :

• Azure Policy obligatoire : tags, régions autorisées (Canada Central / Canada Est), SKUs autorisés.
• Budgets et alertes par souscription, avec notification automatique à 70 %, 90 %, 100 % de consommation mensuelle.
• Comité FinOps mensuel : DSI, finance, business owners, revue des dépenses et des écarts.
• Processus de demande de ressource avec validation business + estimation de coût avant provisioning.
• Indicateurs intégrés au tableau de bord direction : coût Azure par direction, par application, par utilisateur (selon le cas).

Retour terrain : −30 % en 6 mois pour une municipalité québécoise

Une municipalité de la grande région de Montréal nous a confié son optimisation Azure en 2024. Facture initiale : 78 000 $/mois. Après 6 mois de FinOps :

• Reserved Instances sur 64 % du compute stable : économie 22 000 $/mois.
• Rightsizing de 47 VMs surdimensionnées : économie 9 800 $/mois.
• Extinction automatique de 23 environnements dev/test hors heures : économie 6 200 $/mois.
• Storage tiering sur 18 To de logs et archives : économie 4 100 $/mois.
• Suppression de 340 ressources orphelines : économie ponctuelle de 31 000 $.
• Total : facture mensuelle passée de 78 000 $ à 36 000 $, soit −54 % sur 6 mois, bien au-delà de l'objectif initial de −30 %.

Les pièges qui annulent les gains

Trois pièges récurrents que nous voyons annuler 6 mois d'efforts FinOps :

Premier piège : Reserved Instance sur une charge qui va migrer dans 3 mois. Engagement 3 ans = perte sèche. Toujours valider le roadmap applicatif avant tout engagement.

Deuxième piège : extinction automatique sans communication. Un environnement dev éteint le vendredi soir, équipe de dev qui veut travailler le samedi matin, sentiment de blocage. Toujours documenter le mécanisme et le bouton « reprise manuelle ».

Troisième piège : optimisation faite, mais reprise des mauvaises habitudes en 3 mois. Sans gouvernance permanente, la dette revient. Le FinOps n'est pas un projet, c'est un mode opératoire continu.