Entrazure
Ce que le mandat tranche
L’architecture cible. Ce qui a sa place dans Azure, ce qui reste sur site sous Azure Arc, ce qui est retiré plutôt que déplacé, et ce qui attend parce que la justification n’est pas encore là. Le livrable nomme les services de plateforme au lieu de nommer des catégories : une architecture cible qui annonce « une plateforme de données » ne peut pas être chiffrée, alors qu’une architecture cible qui annonce Microsoft Fabric avec un modèle d’espaces de travail gouverné, oui.
Le choix de plateforme. Stratégie de régions et résidence des données, frontière entre services gérés et machines virtuelles, et consolidation ou non de l’identité dans un seul locataire Microsoft Entra ID. Chaque choix est consigné avec son coût, son responsable et son coût de retour arrière, ce dernier étant justement le chiffre que la plupart des exercices de stratégie omettent.
Faire ou acheter. La question qui décide de la moitié du budget. Là où un service Microsoft fait déjà le travail, le configurer correctement vaut mieux que construire un équivalent et l’entretenir pour toujours : Copilot Studio contre un agent sur mesure, Power BI contre des rapports montés à la main, Azure Integration Services contre une couche d’intégration maison. Et là où acheter enfermerait un processus d’affaires central dans quelque chose que vous ne pourrez pas déplacer, nous le disons aussi. Logic Apps en est l’exemple honnête, et de quel côté de la ligne tombe un processus donné se décide par écrit avant que qui que ce soit construise dessus.
Le séquencement. Ce qui vient en premier est une question de dépendances, pas de préférence. La landing zone avant la migration, l’identité avant Copilot, la gouvernance des données avant l’IA. Chaque phase reçoit une condition d’entrée et une condition de sortie, pour qu’on voie quand une phase est réellement terminée plutôt que simplement dépassée en budget.
Le budget. Un modèle de coûts qui sépare l’exploitation, le projet et les licences, avec les hypothèses sur la même page que les totaux. Réservations, Azure Hybrid Benefit et position de licences sont modélisés explicitement, parce qu’une analyse de rentabilité infonuagique qui les ignore se trompe d’un écart qui se verra dès la première revue trimestrielle.
À qui appartient tout ça ensuite. Le registre appartient à votre organisation et il est écrit pour être lu par des gens qui n’étaient pas dans la salle. Une stratégie qui vit dans la tête d’une seule personne est un risque pour vous, de quelque côté de la table que cette personne se trouve. Nous n’en produisons donc pas.
Pourquoi un registre de décisions plutôt qu’une présentation
Une présentation est optimisée pour la réunion. Un registre de décisions est optimisé pour les dix-huit mois qui suivent, c’est-à-dire pour le moment où les questions arrivent vraiment.
Chaque décision occupe une page : le contexte, les options réellement envisagées, ce qui a été retenu, pourquoi, ce que coûterait le retour arrière, et qui a tranché. La forme est celle que les équipes d’ingénierie utilisent déjà pour documenter leurs décisions d’architecture, et elle vit dans votre dépôt à côté du code d’infrastructure : versionnée, relisible en pull request, comparable d’une version à l’autre.
Ce format survit au roulement de personnel des deux côtés. Il survit aussi à un audit, parce que « pourquoi la production est-elle configurée comme ça ? » obtient une réponse écrite et datée, ce qui est une position nettement meilleure qu’une diapositive que personne ne retrouve.
Comment se déroule le mandat
Phase 1, les faits. Accès en lecture seule au parc, plus les contrats, la position de licences et la dépense réelle. Entretiens avec les personnes qui exploitent, pas avec celles qui présentent. Rien n’est conçu à cette étape et rien n’est touché en production.
Phase 2, les options. Deux ou trois architectures cibles crédibles, chacune chiffrée, chacune avec ce qu’elle ferme comme portes, dit clairement. Les options que nous ne recommandons pas sont quand même rédigées : une stratégie qui ne contient qu’une option n’est pas une stratégie.
Phase 3, les décisions. Des séances de travail où les décisions se prennent au lieu de se reporter. Ce qui ne peut pas être tranché devient une question ouverte consignée, avec un responsable et une date, donc visible plutôt que discrètement absente.
Phase 4, la version pour le conseil. Le même contenu, en plus court : ce qui est demandé, ce que ça coûte, ce que ça achète, et ce qui arrive si rien n’est approuvé. Écrit pour qu’un administrateur non technique puisse le contester, parce qu’un budget qu’on ne peut pas contester est en général un budget que personne n’a lu.
Ce que vous gardez
- Le registre de décisions, une page par décision, dans votre organisation Git.
- Une architecture cible qui nomme les services dont elle dépend.
- Un modèle de coûts séparant exploitation, projet et licences, aux hypothèses modifiables.
- Une feuille de route par phases, avec conditions d’entrée et de sortie et un coût par phase.
- Le registre des questions ouvertes, avec un responsable et une date pour chacune.
- La version destinée au conseil, dans le format que vos administrateurs lisent déjà.
Pour qui c’est
Des organisations devant un événement déclencheur : un bail de centre de données qui se termine, un renouvellement de virtualisation, une acquisition à absorber, un remplacement d’ERP, un mandat d’IA descendu du conseil, ou un premier engagement sérieux sur Azure. C’est aussi pour celles qui détiennent déjà une feuille de route et soupçonnent ce qui cloche avec elle, à savoir qu’elle a généralement été écrite par le fournisseur qui vend le plus gros poste qu’on y trouve.
Le mandat fonctionne particulièrement bien juste avant une construction : les décisions qu’il règle sont exactement celles qu’un déploiement de landing zone Azure devrait sinon improviser en première semaine.
Pour qui ce n’est pas
Si la destination est déjà arrêtée et financée, passez votre chemin et construisez. Le mandat de landing zone ou celui de migration infonuagique est un meilleur usage de l’argent.
Si ce que vous cherchez est un document qui ratifie une décision déjà prise, nous sommes le mauvais cabinet. Nous écrirons ce que nous pensons vraiment, y compris le passage où la direction retenue coûte plus cher que l’autre, et nous payer pour être d’accord avec vous est un mauvais rapport qualité-prix.
Si le parc est petit, stable et que personne ne demande de changement, un mandat de stratégie est un frais de structure. Achetez plutôt un audit et agissez sur les trois constats qui comptent.
Pages liées
- Modernisation du système d’information, quand la contrainte est un parc hérité plutôt qu’une page blanche.
- Landing zone Azure, la première construction que la plupart des feuilles de route séquencent.
- Direction SI à temps partagé, quand la feuille de route a besoin de quelqu’un qui en répond mois après mois.
- Audit Azure, le point d’entrée de deux semaines quand la question est plus étroite.
- Tous les services Azure, le catalogue dans lequel une feuille de route puise.
Questions fréquentes
Est-ce un document ou un projet ?
C’est un mandat au périmètre fixe qui produit des documents dont vous êtes propriétaire : un registre de décisions, une architecture cible, une feuille de route chiffrée et la version destinée au conseil. Ce n’est pas une entente d’accompagnement à durée indéterminée, et ce n’est pas une phase de découverte qui glisse tranquillement vers la réalisation. Le périmètre et la date de restitution sont convenus avant la signature.
Qui l’écrit ?
Une équipe d’architectes seniors, qui travaille comme une pratique et non comme une personne. Chaque décision est consignée avec son contexte et sa raison, relue à l’interne avant de vous parvenir, puis déposée dans votre dépôt. C’est délibéré : une stratégie qui n’a de sens que pour celui qui l’a écrite est une dépendance que vous n’avez pas demandée.
Vous êtes partenaire Microsoft. La réponse sera-t-elle toujours Azure ?
Pas toujours, et le registre dit où elle ne l’est pas. Nous sommes partenaire Microsoft AI Cloud et CSP direct, ce qui figure en première page du rapport plutôt que de se découvrir plus tard. Quand une charge est moins chère ou plus sûre là où elle tourne déjà, c’est la recommandation, et Azure Arc sert à la garder sous un seul modèle d’exploitation.
Pouvez-vous travailler avec notre partenaire actuel ?
Oui, et c’est fréquent. La stratégie nomme ce que chaque partie fait bien et ce qui devrait bouger. Nous n’exigeons pas le remplacement du fournisseur en place et nous ne touchons aucune commission d’apport, donc l’argument de séquencement tient debout tout seul.
La feuille de route nous engage-t-elle à vous confier la réalisation ?
Non. Chaque livrable est écrit pour être exécuté par quelqu’un d’autre : services nommés, conditions d’entrée et de sortie par phase, modèle de coûts aux hypothèses visibles. Si nous ne sommes pas le bon cabinet pour la construction, la feuille de route fonctionne quand même. Une feuille de route que nous seuls pourrions exécuter serait un document de vente.
Et si la direction ne s’entend pas sur la destination ?
Alors c’est le premier constat du rapport, écrit en clair. Un désaccord sur la cible est un problème de gouvernance, pas d’architecture, et aucune quantité de conception ne le résout. Nous pouvons animer la décision et consigner ce qui a été convenu. Nous ne pouvons pas décider à votre place.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.