Entrazure
Ce que nous construisons
Le mandat commence par quatre semaines de construction, puis devient une exploitation. Nous ne reprenons pas un parc sans l’avoir d’abord mis dans un état défendable : hériter d’une infrastructure non documentée et l’appeler infogérée, c’est la recette d’une déception partagée.
Une supervision sur laquelle on agit. Azure Monitor avec des règles d’alerte réglées sur ce qui compte, acheminées vers une personne, débarrassées des valeurs par défaut bruyantes. Un canal d’alertes que personne ne lit n’est pas de la supervision, c’est une archive pour la revue post-incident.
Correctifs et cycle de vie. Azure Update Manager, fenêtres de maintenance convenues par environnement, conformité des correctifs rapportée mensuellement, et un chemin d’escalade pour la machine qui échoue toujours. Les fins de support des systèmes et de SQL sont suivies d’avance, pas découvertes par un scanner.
Des sauvegardes que vous avez testées. Couverture vérifiée contre une liste écrite de ce qui doit être restaurable et en combien de temps. Les restaurations sont testées sur horaire. Une sauvegarde jamais restaurée est une croyance, pas un contrôle.
Posture et dérive des politiques. Score de sécurité Defender for Cloud suivi avec une cible de remédiation mensuelle, conformité Azure Policy rapportée, et chaque exception datée et attribuée. Les exceptions expirent par défaut.
Gestion des coûts avec des actions nommées. Azure Cost Management et Azure Advisor revus chaque mois, traduits en une courte liste de changements précis avec l’économie estimée à côté de chacun. Pas un tableau de bord : une liste de décisions. La couverture des réservations et des plans d’économies est réexaminée chaque trimestre.
L’hybride sous un seul modèle. Azure Arc ramène les serveurs, instances SQL et clusters restés sur site sous les mêmes politiques et la même supervision que le parc Azure.
Une revue d’architecture trimestrielle. Une séance par trimestre pour prendre du recul : ce qui a changé sur la plateforme, ce que votre parc fait désormais mal, ce qui devrait être retiré, et ce que nous ferions autrement en repartant de zéro.
Ce que le FinOps change réellement
La plupart des chantiers de coûts échouent parce qu’ils produisent un rapport au lieu d’un changement. Le rapport est juste, tout le monde l’approuve, et rien n’est éteint parce que personne n’est propriétaire de la décision et que personne n’est certain que la chose est inutilisée.
Nous procédons autrement. Chaque mois produit au plus dix actions, chacune avec un propriétaire nommé, une économie estimée et un risque énoncé. Tout ce qui porte un risque réel passe par le même processus de changement que n’importe quelle modification de production. Les gains sont peu spectaculaires et ils se répètent d’un parc à l’autre : du hors production allumé 168 heures par semaine pour servir une semaine de 45 heures, des machines encore dimensionnées d’après le serveur physique qu’elles remplacent, du stockage jamais descendu de palier, des disques et adresses IP orphelins, et des réservations achetées une fois puis oubliées.
Le modèle de coûts est bâti dans votre souscription, avec vos données, et il vous reste.
Informatique soutenable et efficacité du nuage
Commençons par la partie honnête : ce volet recoupe presque entièrement le travail FinOps ci-dessus, et l’argument du coût reste le plus fort. Une machine virtuelle éteinte la nuit ne coûte rien et n’émet rien, et dans toutes les discussions que nous avons eues, c’est la facture qui fait approuver le changement. Nous n’allons pas prétendre le contraire pour vendre un programme de développement durable à part, et nous n’en vendons pas.
Ce qui relève vraiment du mandat, c’est le volet efficacité du même parc. Il mérite d’être nommé, parce que les questions arrivent d’une autre partie de l’organisation.
Les émissions à côté des coûts dans la revue mensuelle. Azure publie des données d’émissions pour vos souscriptions, et nous les plaçons à côté des chiffres de coûts dans le même rapport mensuel plutôt que dans un document que personne ne lit hors de l’équipe développement durable. L’idée est simple : la personne qui décide d’éteindre un environnement hors production voit les deux chiffres en même temps.
Le choix de région selon l’intensité carbone. Les régions Azure ne tirent pas leur électricité du même réseau, et là où la résidence des données, la latence et la disponibilité des services laissent un vrai choix, l’intensité carbone est un critère de départage légitime. Précisons que dans le travail réglementé au Canada, le choix est le plus souvent déjà fait par la résidence, et nous n’allons pas faire miroiter une option qui n’existe pas.
Le dimensionnement au juste et l’extinction programmée. Les mêmes gestes que le travail sur les coûts : des machines encore dimensionnées d’après le serveur physique qu’elles remplacent, du hors production allumé 168 heures par semaine pour une semaine de 45 heures, du stockage jamais descendu de palier, des disques et des adresses orphelins que personne n’a supprimés. Chacun de ces gestes réduit la consommation et la facture ensemble.
La mise hors service comme action à part entière. La charge la plus propre et la moins chère est celle qui a été décommissionnée. La revue d’architecture trimestrielle demande ce qui devrait être retiré, et cette question appartient autant à ce volet-ci qu’à la conversation sur les coûts.
Viennent maintenant les limites, qui comptent plus que l’argumentaire. Nous ne livrons pas de rapport de durabilité certifié ni audité, nous ne sommes pas un organisme d’attestation, et les données d’émissions proviennent de la publication de Microsoft, avec sa méthodologie et son périmètre. Ce que vous obtenez, c’est la liste d’actions mensuelle avec le chiffre d’émissions à côté du chiffre de coûts, et l’historique de ce qui a changé et quand. C’est une entrée utilisable pour une déclaration CSRD ou un questionnaire ESG client. Ce n’est pas la déclaration elle-même, et la comptabilité comme son attestation restent chez vous et chez votre auditeur. Nous n’attacherons pas non plus une économie de carbone à une action que nous ne pouvons pas rattacher à un changement de ressource précis, ce qui écarte la plupart des chiffres que ce domaine aime citer.
Si le moteur est purement financier, l’optimisation des coûts infonuagiques est le chemin le plus court, et c’est le même travail en dessous.
Comment le mandat se déroule
Semaines 1 et 2, inventaire et base de référence. Ce qui existe, ce que ça coûte, ce qui est exposé, ce qui n’est pas corrigé, ce qui n’est pas sauvegardé. Modèle d’accès convenu, nos accès accordés par rôles privilégiés à durée limitée plutôt qu’en administration permanente.
Semaine 3, remédiation des constats urgents. La courte liste qui ne peut pas attendre le régime de croisière : exposition publique, sauvegardes manquantes, certificats expirés, systèmes exposés non corrigés.
Semaine 4, instrumentation. Alertes, tableaux de bord, vues de coûts, calendriers de correctifs et cadence de reddition. Les procédures sont écrites et revues avec votre équipe.
Chaque mois ensuite. Un rapport écrit : posture, conformité des correctifs, incidents, tendance de coûts et liste d’actions. Une séance de travail, pas une présentation envoyée par courriel.
Chaque trimestre. Revue d’architecture, revue des réservations et des plans d’économies, test de reprise après sinistre, et feuille de route recalée.
Ce que vous gardez
- L’inventaire et l’évaluation de référence, avec les constats et leur état de remédiation.
- Les procédures de chaque tâche d’exploitation récurrente, écrites pour votre équipe.
- La configuration de supervision, d’alertes et de tableaux de bord, dans votre locataire.
- Le modèle de coûts et les listes d’actions mensuelles, y compris les actions refusées et pourquoi.
- L’historique de conformité des correctifs et de vérification des sauvegardes, utilisable en audit.
- Les revues d’architecture trimestrielles, qui forment ensemble l’histoire écrite du parc.
Pour qui c’est
Des organisations de 50 à 2 000 personnes en production sur Azure sans équipe de plateforme dédiée, ou avec une équipe assez petite pour que l’exploitation dévore la feuille de route. C’est la suite naturelle d’une migration vers Azure, et ça fonctionne mieux sur un parc qui repose sur une landing zone Azure : c’est la gouvernance qui rend un parc bon marché à exploiter.
Pour qui ce n’est pas
Si vous cherchez un centre d’assistance 24/7 pour vos utilisateurs finaux, nous ne faisons pas ça, et il faut l’acheter à quelqu’un qui le fait bien.
Si vous voulez faire infogérer un parc que vous ne nous laisserez pas modifier, l’entente ne tiendra pas. Nous pouvons exploiter une architecture avec laquelle nous sommes en désaccord, pas une architecture que nous n’avons pas le droit de corriger.
Et si l’objectif est uniquement de baisser la facture sans rien changer à la façon de déployer ou d’ordonnancer, attendez-vous à une vague d’économies puis à un plateau. Le contrôle durable des coûts est une pratique d’exploitation, et il se décide en amont, dans l’infrastructure en code.
Pages liées
- Migration vers Azure et sortie de VMware, ce qui précède habituellement ce mandat.
- Cybersécurité et Entra ID, le volet sécurité du même parc.
- DevOps et infrastructure en code, là où le coût d’exploitation se décide vraiment.
- Tous les services Azure, le catalogue complet des mandats.
Questions fréquentes
Qu’est-ce qui est réellement inclus ?
Supervision et réponse aux alertes, correctifs par Azure Update Manager, vérification des sauvegardes, dérive des politiques et de la posture, revue de coûts mensuelle avec actions nommées, et revue d’architecture trimestrielle. Les travaux de projet sont chiffrés séparément : intégrer la livraison dans une provision, c’est la transformer discrètement en file d’attente.
Quel est votre délai de réponse ?
Les cibles de réponse sont convenues par environnement et écrites dans l’entente, pas publiées comme argument de vente. Ce que nous nous engageons à écrire, c’est que la personne qui répond a déjà travaillé sur votre parc. Un premier intervenant qui découvre votre architecture pendant l’incident, c’est le vrai défaut de la plupart des contrats de support.
Faut-il transférer nos souscriptions chez vous ?
Non. Nous pouvons exploiter un parc facturé directement par Microsoft, par un autre partenaire ou sous entente Entreprise. Entrazure est CSP direct et la facturation consolidée est disponible si vous la voulez, mais ce n’est jamais une condition, et le conseil reste chiffré séparément des licences.
De combien pouvez-vous réduire notre facture Azure ?
Nous ne donnons pas de pourcentage avant d’avoir regardé. Les gains reviennent toutefois avec régularité : disques détachés et adresses IP publiques orphelines, environnements hors production allumés la nuit et la fin de semaine, machines virtuelles encore dimensionnées d’après une fiche technique sur site, stockage dans le mauvais palier, et couverture de réservations que personne n’a revue depuis l’achat.
Pouvez-vous gérer ce qui reste sur site ?
Oui, avec Azure Arc. Serveurs, instances SQL et clusters Kubernetes hors Azure passent sous les mêmes politiques, la même supervision et la même gestion des correctifs. Un seul modèle d’exploitation au lieu de deux vaut souvent plus cher que l’outillage lui-même.
Que se passe-t-il si nous mettons fin au contrat ?
Vous gardez tout : le code d’infrastructure, les procédures, la configuration de supervision, les tableaux de bord et le modèle de coûts, dans votre locataire et votre dépôt depuis le premier jour. Il n’y a aucun plan de gestion à nous à retirer, aucun agent qui cesse de fonctionner. La sortie est une séance de transfert, pas un projet.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.