Script oral de soutenance — 25 minutes

Hamid HAMILA — Master IRS P38 — VINCI CONSTRUCTION SI

Les slides de transition (5, 7, 11, 15, 19, 23, 27, 30) ne sont pas scriptées : tu annonces le verbe, tu respires, tu enchaînes. Le temps indiqué par slide est une cible ; le total fait 25 minutes.

Rappel des analogies à placer (une par projet) : la porte fermée à clé (sauvegardes), l'annuaire téléphonique (DNS), la jauge d'essence (quotas), le pont (Power BI).

SLIDE 1 — Titre (45 s)

Bonjour à tous, merci de m'accueillir. Je m'appelle Hamid Hamila, je termine mon Master IRS en alternance chez VINCI CONSTRUCTION SI, dans l'équipe Cloud Public Azure, sous la responsabilité d'Ivan Pecnik.

L'an dernier, je vous avais présenté la construction d'un service : une solution de postes de travail virtuels, Azure Virtual Desktop. Cette année, je vais vous parler de ce qui vient après. Quand la plateforme existe, qu'elle grossit, et qu'il faut garantir qu'elle fonctionne correctement, durablement, et sans dépendre des personnes qui l'ont mise en place.

SLIDE 2 — Et si tout fonctionnait déjà ? (1 min)

Je commence par la phrase qui résume mon année : et si tout fonctionnait déjà ?

Quand je suis arrivé sur mes quatre sujets, rien n'était cassé. Les sauvegardes s'exécutaient. Les ressources réseau se déployaient. Les quotas étaient consultables dans le portail. Une passerelle Power BI tournait en production. Tout fonctionnait.

Ce qui manquait, dans les quatre cas, ce n'était pas la fonction. C'était la garantie qu'elle fonctionne correctement, et durablement. Et cette garantie reposait toujours sur la même chose : une personne. Quelqu'un qui vérifie. Quelqu'un qui recopie sans se tromper. Quelqu'un qui pense à regarder. Quelqu'un qui se souvient.

Retenez ces quatre verbes, vous allez les revoir tout au long de la présentation.

SLIDE 3 — Sommaire (45 s)

Voici le déroulé. Après un mot sur l'entreprise et le contexte, j'aborderai mes quatre projets, chacun résumé par un verbe : prouver, corriger, anticiper, transmettre.

Ces quatre verbes suivent aussi une progression dans le temps. Prouver, c'est le passé : est-ce que tout a bien tourné cette nuit ? Corriger, c'est le présent : ce qui est déployé est-il conforme en ce moment ? Anticiper, c'est le futur : jusqu'où puis-je aller avant d'être bloqué ? Et transmettre, c'est la durée : quelqu'un saura-t-il refaire ceci dans deux ans ?

Je terminerai par la réponse à ma problématique et ce que je retire de cette année.

SLIDE 5 — Du groupe VINCI à VINCI CONSTRUCTION SI (1 min)

Rapidement, le contexte. VINCI est un leader mondial des concessions, de la construction et de l'énergie : 285 000 collaborateurs, 120 pays, organisé en pôles autonomes, avec une culture de décentralisation très forte.

VINCI Construction, c'est la branche bâtiment et génie civil : 1 300 entreprises, 117 000 personnes, près de 32 milliards de chiffre d'affaires.

Et VINCI CONSTRUCTION SI, à Nanterre, est l'entité qui gère le système d'information de toute cette branche, avec un objectif : un SI mutualisé, performant et sécurisé.

Ce qu'il faut retenir pour la suite, c'est l'échelle. Des dizaines d'applications, plusieurs équipes, plusieurs souscriptions Azure. À cette échelle, ce qui repose sur une personne ne tient pas.

SLIDE 6 — Mon rôle et le socle technique (1 min)

J'occupe le poste d'apprenti ingénieur Cloud Public dans le pôle Hosting, au sein de la direction IT Infra & Opérations. Notre équipe conçoit et déploie des architectures sur Microsoft Azure dans le cadre du programme Move2Cloud, la migration progressive de nos systèmes vers le cloud.

Tout est fait en Infrastructure as Code, c'est le schéma de gauche. Concrètement : au lieu de cliquer dans un portail, on décrit l'infrastructure dans des fichiers versionnés avec Terraform, Ansible configure ensuite les machines, et une pipeline Azure DevOps déploie le tout automatiquement. L'avantage, c'est que chaque déploiement est reproductible et traçable.

Mes missions vont de l'architecture Cloud au scripting, en passant par le traitement de tickets et l'accompagnement des projets Move2Cloud.

La différence majeure avec ma première année : je ne travaillais plus sur une application, mais sur des dispositifs transverses qui servent toute la plateforme, avec des interlocuteurs au-delà de l'équipe Cloud, notamment les référents de la certification ISO 27001.

SLIDE 8 — Le seuil où la vigilance ne suffit plus (1 min 15)

Pourquoi ce sujet est-il devenu prioritaire cette année ? Trois pressions se sont conjuguées.

La croissance, d'abord. La stratégie Move2Cloud fonctionne : le nombre de ressources sur Azure augmente en continu, avec de plus en plus d'équipes qui déploient, et des niveaux de maîtrise très variables.

ISO 27001, ensuite. L'entreprise s'est engagée dans une certification, la norme internationale de sécurité de l'information. Et ça change la nature des exigences. Il ne suffit plus qu'une mesure soit appliquée, il faut pouvoir le prouver à un auditeur, régulièrement, avec des éléments tangibles. Une équipe qui affirme contrôler ses sauvegardes n'apporte aucune preuve. Un rapport automatique quotidien, si.

La maturité, enfin. Les briques essentielles de la plateforme sont en place. L'effort peut donc se déplacer de la construction vers la fiabilisation. C'est le moment naturel pour traiter la gouvernance.

SLIDE 9 — Trois façons dont une plateforme se dégrade (1 min 15)

Une plateforme jeune fonctionne très bien sur des bonnes pratiques partagées : chacun connaît les conventions, sait où regarder. Mais ce mode de fonctionnement se dégrade, selon trois mécanismes que j'ai tous rencontrés cette année.

La dilution. Plus le parc grandit, plus une vérification manuelle coûte cher. Contrôler les sauvegardes de quatre souscriptions demande une dizaine de clics par environnement. C'est faisable une fois. Pas tous les matins. Donc on espace, puis on abandonne.

La répétition. Une règle recopiée à la main cent fois finira mal recopiée une fois. Pas par incompétence, par la loi des grands nombres.

L'oubli. Une connaissance qui n'est pas écrite part avec la personne qui la détient. Mon quatrième projet trouve son origine exacte dans le départ de l'architecte qui avait conçu le dispositif.

Ces trois mécanismes ont un point commun : ils sont silencieux. Le problème n'est pas que la plateforme tombe en panne. C'est qu'elle devienne progressivement impossible à garantir.

SLIDE 10 — Quatre projets, une même logique (1 min 30)

Ces quatre projets ont été menés indépendamment, à des moments différents de l'année. Leur unité n'a pas été décidée au départ, elle est apparue en les traitant.

Regardez le tableau ligne par ligne. Les sauvegardes tournaient, il manquait la preuve, et ça dépendait de quelqu'un qui vérifie. Les Private Endpoints se déployaient, il manquait la bonne zone DNS à coup sûr, et ça dépendait de quelqu'un qui copie sans se tromper. Les quotas étaient consultables, il manquait l'alerte avant saturation, et ça dépendait de quelqu'un qui pense à regarder. Une passerelle tournait, il manquait la procédure, et ça dépendait de quelqu'un qui se souvient.

La dernière colonne, c'est toujours une personne. Et cette dépendance a deux défauts rédhibitoires à l'échelle d'un groupe : elle ne passe pas à l'échelle, et elle ne survit pas au départ de quelqu'un.

D'où ma problématique : comment faire évoluer une plateforme Cloud d'entreprise d'un fonctionnement qui repose sur la vigilance des personnes vers un fonctionnement garanti par ses propres mécanismes ?

Ma réponse tient en une phrase, que les quatre projets vont illustrer : déplacer systématiquement la connaissance et la vigilance humaines vers des mécanismes qui s'exécutent sans elles.

03 — PROUVER

SLIDE 12 — Une sauvegarde non vérifiée n'est pas une sauvegarde (1 min 30)

Premier projet : prouver. La question posée est celle du passé : est-ce que tout a bien tourné cette nuit ?

L'analyse de risques ISO 27001 menée sur notre périmètre Azure a produit un catalogue de mesures de remédiation. Celle que vous voyez, la SM-07-025, m'a été assignée en binôme, avec une criticité "Critical" et une échéance. Elle est simple à énoncer : vérifier chaque jour que les sauvegardes de la veille ont réussi.

La nuance qui donne tout son sens au projet : l'entreprise sauvegardait déjà. Ce qui manquait, c'était la preuve. C'est comme fermer sa porte à clé : ça ne suffit pas, l'auditeur veut la trace que quelqu'un a vérifié chaque soir. Sans cette preuve, un audit considère la mesure comme non appliquée, même si les données sont parfaitement protégées.

L'état des lieux a posé trois constats. Les sauvegardes étaient éclatées sur plusieurs souscriptions, DEV, UAT, PPD, PRD. Elles reposaient sur deux mécanismes techniques différents : les machines virtuelles utilisent la sauvegarde native d'Azure, les bases de données sont sauvegardées par un script PowerShell planifié. Et il n'existait aucune vue centralisée. Répondre à "est-ce que tout a bien tourné ?" demandait une dizaine de clics par souscription. Donc, en pratique, personne ne posait la question.

Les livrables attendus étaient clairs : un tableau de bord consultable à la demande, et un rapport quotidien envoyé automatiquement par mail.

SLIDE 13 — Architecture (1 min 45)

Aucune architecture n'existait. J'ai conçu la solution de bout en bout, de l'analyse de l'existant jusqu'au document d'architecture, et je l'ai présentée en comité d'architecture pour validation avant déploiement. Ce sera le cas pour les trois premiers projets.

Le principe tient en une phrase : faire converger tous les journaux de sauvegarde vers un point unique, puis exposer cette donnée de deux manières.

Le point unique, au centre du schéma, c'est un Log Analytics Workspace, la base de données de logs d'Azure. Toutes les ressources de sauvegarde y déversent leur activité grâce à un mécanisme natif d'Azure, les Diagnostic Settings, une sorte de tuyau : on l'active sur une ressource, on désigne la destination, et les journaux y sont recopiés automatiquement.

Les sources sont hétérogènes, et c'est là qu'a résidé l'essentiel du travail. Pour les VM, le coffre de sauvegarde natif sait émettre ses journaux, il suffit de brancher le tuyau. Pour les bases, c'était plus délicat : le script écrivait du texte libre, impossible à exploiter proprement. Plutôt que de faire de l'analyse de texte fragile, j'ai instrumenté le script lui-même pour qu'il émette des marqueurs structurés : environnement, projet, type de base, nom de la base. Quelques lignes ajoutées, et toute nouvelle base apparaît dans le monitoring sans rien modifier ailleurs.

Côté exploitation, deux consommateurs lisent cette base : un Workbook, le tableau de bord natif d'Azure, pour consulter à la demande, et une Logic App, un automate, qui exécute chaque matin à huit heures les mêmes requêtes et envoie un rapport par mail à l'équipe.

L'intérêt de cette architecture, c'est son découplage : les sources ne connaissent pas les consommateurs. Brancher une nouvelle souscription revient à activer un réglage de plus ; le dashboard et le mail l'intègrent d'eux-mêmes. Le tout est déployé en Terraform via une pipeline, avec toute la configuration externalisée dans un fichier de variables : changer un destinataire ou l'heure d'envoi, c'est une ligne, sans toucher au code.

SLIDE 14 — Résultats : les anomalies rendues visibles (1 min 30)

Le dispositif est en production. À gauche, le rapport que l'équipe reçoit chaque matin à huit heures, par environnement, VM et bases, avec le statut de chaque sauvegarde. À droite, le tableau de bord.

Quelques chiffres. Le dispositif supervise aujourd'hui 28 machines virtuelles et 56 bases de données sur plusieurs souscriptions. Sur les 90 derniers jours, il a analysé environ 6 000 travaux de sauvegarde. Côté VM, 100 % de succès. Côté bases, 98 %. Et ces 2 % représentent 104 anomalies qui ont nécessité une intervention. Vous en voyez une sur la capture : un échec en DEV, 93,8 %. C'est exactement ce que voit l'équipe le matin.

Sans le dispositif, ces échecs seraient restés invisibles. On les aurait découverts au moment d'une demande de restauration, c'est-à-dire précisément quand on ne peut plus rien faire. C'est le risque que la mesure ISO visait : pas l'absence de sauvegarde, mais l'illusion d'en avoir une.

Et il y a eu un effet inattendu. En rendant les sauvegardes des bases observables, le dispositif a révélé deux faiblesses du mécanisme existant : une planification manuelle, une nouvelle base n'est sauvegardée que si quelqu'un la déclare, et une politique de rétention non conforme. L'outil conçu pour prouver la conformité est devenu l'outil qui révèle la non-conformité. Un POC est en cours pour automatiser la découverte des nouvelles bases et la mise en conformité.

Je tiens à dire les limites aussi : le dispositif exige une gouvernance stricte, un coffre par souscription et le respect des conventions de nommage, et le branchement automatique des nouvelles souscriptions est encore en déploiement.

04 — CORRIGER

SLIDE 16 — Une information recopiée finit recopiée de travers (1 min 45)

Deuxième projet : corriger. La question est celle du présent : ce qui est déployé maintenant est-il conforme ?

Un peu de contexte. Chez VINCI, aucun service cloud n'est exposé sur Internet. Chaque service, base de données, coffre de secrets, stockage, est projeté dans notre réseau privé via un Private Endpoint, avec une adresse interne. Mais pour que les applications le trouvent, il faut un annuaire, ce qu'on appelle une zone DNS privée. C'est exactement l'annuaire téléphonique : un chiffre faux, et l'appel part chez le mauvais interlocuteur. Il y a une vingtaine de zones, une par type de service, c'est imposé par Azure.

Le problème n'était pas dans le réseau. Il était dans notre code. Vous le voyez sur la capture : pour chaque déploiement, il fallait recopier l'identifiant de la bonne zone, une centaine de caractères. Personne ne les tape de mémoire. On copie un bloc précédent, on l'adapte, souvent en fin de journée.

Et surtout, l'erreur est silencieuse. Si on se trompe de zone, l'identifiant reste valide, le déploiement réussit, tout est vert dans le portail. Rien ne signale l'erreur au moment où elle est commise.

Ce risque n'est pas resté théorique. Le cas le plus marquant : une application métier dont la base PostgreSQL avait été rattachée à la zone MySQL. Un mot faux dans l'URL. Le déploiement s'était déroulé sans erreur. Le problème n'est apparu qu'au premier démarrage, sous la forme d'un simple délai de connexion. Tous les indices pointaient dans la mauvaise direction : la base répondait, le réseau était approuvé, le pare-feu était correct. Plusieurs personnes mobilisées pendant plusieurs heures, pour un mot. Ce rapport disproportionné entre la cause et son coût a déclenché le projet.

SLIDE 17 — Architecture (1 min 45)

Le besoin s'est reformulé ainsi : la correspondance entre un type de service et sa zone DNS est une règle déterministe, globale, sans exception. Il fallait la retirer des mains de celui qui déploie.

L'outil, c'est Azure Policy, le service de gouvernance d'Azure : des règles appliquées automatiquement à toutes les ressources d'un périmètre, en continu. Son intérêt fondamental, c'est qu'il ne dépend d'aucune action humaine. Une équipe qui déploie se voit appliquer la règle sans même avoir à la connaître.

J'ai fait un choix structurant : corriger plutôt que bloquer. Une policy peut interdire une création. Mais bloquer les déploiements transforme l'équipe de gouvernance en goulot d'étranglement, et ça pousse au contournement. L'approche retenue, c'est l'auto-remédiation : on laisse déployer, et la policy remet en conformité derrière. Elle détecte le Private Endpoint, identifie son type de service, et lui rattache la bonne zone.

Résultat sur le code, c'est la partie droite du schéma : le bloc DNS disparaît purement et simplement du code des projets. Une information qu'on n'écrit pas est une information qu'on ne peut pas écrire de travers.

Les tests ont révélé une limite d'Azure Policy qui n'est écrite nulle part dans la documentation, et qui est à mes yeux l'apport technique le plus intéressant du projet. Une policy sait ajouter, elle ne sait pas réparer. Quand la configuration DNS est absente, elle la déploie. Quand elle existe mais qu'elle est fausse, exactement le cas qui avait causé les pannes, la policy est impuissante. Ma solution : un script identifie les configurations erronées et les supprime. La ressource repasse dans un état que la policy sait traiter, et la policy reconstruit. Le script ne corrige rien, il détruit ; la logique de reconstruction, elle, n'est écrite qu'à un seul endroit.

SLIDE 18 — Résultats : une règle, un seul endroit (1 min)

J'ai conçu, développé et validé le dispositif en comité d'architecture ; le déploiement effectif a été repris par un collègue, qui a assigné les policies au niveau des management groups de la nouvelle plateforme. Vous voyez le résultat sur la capture : les policies sont à 100 % de conformité, et le rattachement DNS porte la mention "deployedByPolicy". C'est la policy qui a fait le travail, sans action des équipes.

En parallèle, le problème a aussi été traité à la source : nos modules Terraform internes ont été refondus pour porter eux-mêmes la correspondance. Un projet qui utilise le module "coffre de secrets" reçoit automatiquement la bonne zone, sans la connaître.

Les deux mécanismes forment une défense en profondeur : le module garantit que ce qui est déployé par la voie standard naît correct ; la policy rattrape ce qui échappe aux modules, l'existant, les ressources créées à la main. Dans les deux cas, la règle n'est plus écrite qu'à un seul endroit, et plus jamais dans le code de chaque projet.

Ce chapitre est le pendant du précédent : le monitoring constate l'état de la plateforme, la gouvernance agit sur cet état.

05 — ANTICIPER

SLIDE 20 — Le Cloud n'est pas illimité, on le découvre trop tard (1 min 45)

Troisième projet : anticiper. La question est celle du futur : jusqu'où puis-je aller avant d'être bloqué ?

Le Cloud est réputé illimité. En réalité, chaque service est encadré par des quotas : des limites fixées par Microsoft, par souscription, par service et par région. Nombre de cœurs de processeur, d'adresses IP, de comptes de stockage. Vous en voyez sur la capture, avec leur taux d'utilisation.

Le comportement d'Azure face à un quota atteint est brutal : aucun avertissement. Tant qu'il reste un cœur disponible, tout fonctionne. Au suivant, le déploiement échoue. Et demander un relèvement à Microsoft prend de quelques heures à plusieurs jours. C'est une voiture sans jauge d'essence : on découvre le réservoir vide au moment de la panne, en plein déploiement, sur un problème que l'équipe ne peut pas résoudre seule.

Le besoin était donc de centraliser la visibilité des quotas sur toutes nos souscriptions, d'avoir une vue globale, et d'être alerté avant d'atteindre les limites.

Première démarche, évaluer l'offre native. Microsoft propose un alerting sur les quotas, mais il est en préversion, il ne couvre que trois familles de services, calcul, machine learning et HPC, alors que nous consommons des quotas sur le réseau, le stockage, les bases de données. Et il n'offre aucune vue multi-souscriptions, l'échelle même à laquelle le problème se pose.

Une fonctionnalité en préversion pose toujours la même question : attendre l'éditeur, ou construire ? Attendre a un coût, ici bien identifié : continuer à découvrir les quotas saturés en production, pour une durée que personne ne pouvait estimer. La distinction déterminante, c'est que le service d'alerting était en préversion, mais pas les API sur lesquelles il repose. Il ne s'agissait donc pas de réinventer une fonctionnalité, mais de descendre d'un niveau d'abstraction et de reconstruire au-dessus des API ce que l'interface ne fournissait pas encore.

SLIDE 21 — Architecture (1 min 30)

C'est le projet où la part de développement a été la plus importante : le collecteur n'est pas la configuration d'un service managé, c'est un programme. Là encore, architecture conçue de bout en bout et validée en comité.

La chaîne suit trois étapes. La collecte, en bas à gauche : une Function App, un service qui exécute du code planifié sans serveur à gérer, écrite en PowerShell, réveillée toutes les quatre heures. Six relevés par jour donnent une courbe lisible tout en restant économes, un quota n'évolue pas en quelques minutes.

Le collecteur ne travaille pas sur une liste en dur. Il interroge Azure Resource Graph pour découvrir lui-même les souscriptions rattachées au management group, et les régions réellement utilisées. Une nouvelle souscription est prise en compte au relevé suivant, sans rien toucher.

Le point délicat, vous le voyez en haut du schéma : tous les services n'exposent pas leurs quotas de la même façon. Microsoft est en transition vers une API unifiée, mais tous les fournisseurs n'y sont pas raccordés. Le collecteur implémente donc deux chemins : l'API unifiée pour 14 fournisseurs, l'API historique pour 7 autres. C'est le prix de la couverture : 21 fournisseurs au lieu de 3. Et c'est conçu pour être temporaire : à mesure que Microsoft raccorde les fournisseurs restants, il suffira de les déplacer d'une liste à l'autre.

L'ingestion passe par la chaîne moderne d'Azure Monitor, DCE et DCR, qui déclare le schéma attendu : toute donnée non conforme est rejetée à l'entrée. Le contrat de données vit dans l'infrastructure, pas dans le code.

L'exploitation, enfin : un seul tableau de bord filtrable par souscription, région et fournisseur, parce que multiplier les tableaux de bord, c'est multiplier les liens que personne n'ouvre. Et une alerte par mail au seuil de 85 %. Ce seuil est un arbitrage : assez tôt pour obtenir un relèvement auprès de Microsoft, assez haut pour ne pas déclencher sur des variations normales.

SLIDE 22 — Résultats (1 min 15)

Le dispositif est en production depuis août. À droite, le tableau de bord : vous voyez chaque souscription, sa région, le service concerné et le taux d'utilisation maximal, avec un code couleur. À gauche, le mail d'alerte tel que l'équipe le reçoit.

À l'échelle actuelle, plus de vingt souscriptions sont scannées sur plusieurs régions, une dizaine de fournisseurs surveillés, soit plus de mille quotas relevés toutes les quatre heures.

Sur la capture, deux quotas dépassent 85 %, en rouge : ils font l'objet de demandes de relèvement auprès de Microsoft. Trois dépassent 50 %, en orange : c'est la liste de surveillance, ceux qui franchiront le seuil dans les mois à venir au rythme actuel de croissance. C'est précisément l'information que le projet voulait rendre disponible : identifier les saturations avant qu'elles ne deviennent des blocages.

Un dernier point que j'assume : cette solution est probablement destinée à disparaître. Le jour où Microsoft étendra son alerting natif à tous les fournisseurs, elle perdra sa raison d'être. Ce n'est pas un échec, c'est un choix lucide, qui a orienté la conception : la solution ne modifie aucune ressource, rien ne dépend d'elle, et la retirer consistera à supprimer un groupe de ressources. Construire une solution transitoire impose de la construire détachable.

Ce projet complète la progression : le monitoring constate, la policy corrige, la supervision des quotas anticipe. C'est la différence entre superviser une plateforme et la piloter.

06 — TRANSMETTRE

SLIDE 24 — Un héritage peu documenté (1 min 30)

Dernier projet : transmettre. Il est différent des trois autres. Les trois premiers, je les ai conçus. Celui-ci, j'en ai hérité.

Un dispositif fonctionnait en production pour un premier projet, conçu par un architecte Azure qui a depuis quitté l'entreprise. Le dispositif marchait, ce qui prouvait la validité du choix. Mais tout ce qui l'accompagnait, le raisonnement, les alternatives écartées, les prérequis, les pièges, était parti avec lui. L'inventaire de ce qui restait, vous l'avez sous les yeux : un mail avec une présentation de deux diapositives. Rien sur le fonctionnement interne, les flux à ouvrir, les droits nécessaires.

C'est une situation banale en entreprise, et rarement traitée dans les mémoires : la majorité du travail d'un ingénieur ne consiste pas à concevoir sur une page blanche, mais à reprendre ce que d'autres ont construit.

La demande venait d'un nouveau projet, Digit-GI : un rapport Power BI, l'outil de visualisation de données de Microsoft, devant lire une base hébergée dans notre réseau privé. Le problème est frontal. Power BI est un service SaaS, il s'exécute entièrement chez Microsoft, hors de notre réseau. Et toute notre stratégie consiste à enfermer la donnée à l'intérieur. Le service qui doit lire est dehors, la donnée est dedans. Il faut un pont.

Deux choses rendaient la reproduction non triviale. Personne ne savait comment le premier déploiement avait été fait. Et le socle technique avait changé : l'existant reposait sur l'ancienne licence Power BI Premium, le nouveau projet sur une capacité Microsoft Fabric, une vraie ressource Azure avec ses propres rôles. Il ne s'agissait donc pas de recopier, mais de reconstruire sur un socle différent.

Ma démarche : la rétro-ingénierie. Inspecter l'existant côté Azure et côté Power BI, le confronter à la documentation Microsoft pour distinguer ce qui relevait d'un choix VINCI de ce qui était imposé par le produit, et réévaluer les quatre solutions possibles, y compris celles qui n'existaient peut-être pas au moment de la décision initiale.

SLIDE 25 — Architecture (1 min 30)

La réévaluation a confirmé le choix initial : la VNet Data Gateway. Et elle a écarté l'option qui semblait la plus élégante, le Managed Private Endpoint de Fabric, parce que la documentation Microsoft exclut explicitement les modèles sémantiques Power BI de ce mécanisme. Pour notre cas, la VNet Data Gateway est aujourd'hui la seule solution supportée. C'est l'intérêt de confronter une intuition à la documentation.

Le fonctionnement, sur le schéma. On réserve un petit sous-réseau de notre réseau privé, huit adresses, et on en délègue l'usage à Microsoft. Microsoft y déploie et gère lui-même un à trois conteneurs, haute disponibilité incluse. Ni machine virtuelle à maintenir, ni système à mettre à jour de notre côté. C'est un pont managé.

Côté Power BI, en haut, on crée un objet passerelle qui pointe vers ce sous-réseau, et le rapport est configuré pour passer par elle. Les conteneurs ont besoin d'un accès sortant, jamais entrant, vers cinq destinations Microsoft, pour l'authentification et les mises à jour, à autoriser dans notre pare-feu central. Pour atteindre la base, en bas à droite, ils empruntent le routage normal du réseau.

Ce dernier point structure toute la gouvernance : la passerelle peut atteindre tout ce que son réseau peut atteindre. Ce n'est pas un tunnel restreint vers une base précise, c'est une porte sur un périmètre. Un vrai service PaaS, mais un objet à gouverner.

Le livrable central du projet n'est pas la passerelle. C'est le document d'architecture qui manquait. Parce qu'un dispositif non documenté n'est pas un actif, c'est une dette : il fonctionne tant que personne n'y touche et tant que son auteur est là.

SLIDE 26 — D'un cas réussi à une brique réutilisable (1 min 15)

Voici le livrable : le document d'architecture, avec son sommaire à gauche, et les captures du déploiement validé de bout en bout.

Le cœur du document, c'est une procédure en sept étapes, paramétrée par environnement et par code projet. Ce n'est pas la description d'un cas, c'est un gabarit applicable à n'importe quel nouveau projet. Créer le sous-réseau délégué. Ajouter la règle de pare-feu. Demander les droits d'administration sur la capacité. Créer la passerelle côté Power BI. Attribuer le rôle de création de connexion au seul contact technique du projet. Configurer le rapport et tester un rafraîchissement manuel puis planifié. Et septième étape, retirer les droits d'administration temporaires.

Cette dernière étape est volontaire : les droits d'administration ne sont requis que pour un seul geste, et ils sont explicitement retirés à la fin, pour éviter qu'un privilège accordé "le temps de faire" ne devienne permanent par oubli.

La passerelle de Digit-GI aurait pu être déployée sans rien écrire. Elle aurait fonctionné, et le problème initial se serait reposé à l'identique au projet suivant. En produisant le document, on ne livre plus une passerelle : on livre la capacité d'en déployer d'autres. La documentation n'est pas une formalité qui suit le travail technique, c'est ce qui transforme un résultat individuel en capacité collective.

Ce projet clôt la progression : le monitoring constate, la policy corrige, la supervision anticipe, et la passerelle raccorde la plateforme aux usages métier, là où l'infrastructure redevient un moyen : au bout de la chaîne, il y a un rapport que quelqu'un consulte pour décider.

07 — RÉPONSE & RETOUR D'EXPÉRIENCE

SLIDE 28 — Déplacer la vigilance (1 min 45)

Je relie maintenant les quatre projets. Dans les quatre cas, la solution n'a pas consisté à mieux faire ce qui était fait, ni à demander plus de rigueur aux équipes. Elle a consisté à retirer l'exigence des mains humaines et à l'installer dans un mécanisme qui s'exécute sans elles.

Le tableau se lit dans sa dernière colonne. Ce qui est retiré à la personne n'est jamais la même chose : vérifier, savoir, y penser, se souvenir. Un geste, une connaissance, une attention, un souvenir. Mais c'est toujours une chose fragile, qui dépend de la disponibilité, de la mémoire ou de la constance d'un individu.

J'insiste sur un contresens à éviter : il ne s'agit pas de se passer des personnes. Il s'agit de cesser de faire reposer sur elles ce qu'un mécanisme fait mieux : sans se lasser, sans oublier, sans être en congé, et de façon identique la millième fois que la première.

La réponse à ma problématique tient en trois propositions.

Identifier ce qui, dans chaque exigence, repose encore sur une personne. C'est l'étape la moins technique et la plus déterminante. La question "si cette personne n'est pas là demain, qu'est-ce qui casse ?" suffit généralement à faire apparaître la dépendance.

Installer cette exigence dans un mécanisme : un journal qui prouve, une règle qui corrige, une alerte qui prévient, un document qui transmet. Avec deux conditions : ne rien coder en dur de ce que la plateforme sait déclarer, pour rester valable quand elle grandit ; et rester supportable pour les équipes, sinon le mécanisme sera contourné.

Documenter les limites de ce transfert plutôt que les masquer. Chacun de mes mécanismes a produit sa dette : un contournement, un paramètre figé, une obsolescence programmée. Ces dettes sont acceptables parce qu'elles sont identifiées, localisées et motivées.

Une plateforme gouvernée, ce n'est donc pas une plateforme où tout est automatisé, ni une plateforme sans dette. C'est une plateforme dont on peut démontrer l'état sans dépendre de la mémoire de quelqu'un, y compris démontrer ce qui ne va pas encore.

SLIDE 29 — Retour d'expérience (1 min 30)

Ce que je retire de cette année, en deux volets.

Techniquement, ma progression la plus nette est sur l'observabilité et l'interrogation de données : deux projets reposent entièrement sur Azure Monitor et son langage de requête, et je suis passé de requêtes simples à des constructions élaborées. J'ai travaillé Azure Policy en profondeur, et surtout ses limites, qui ne sont écrites nulle part : ça se découvre en testant. J'ai appris à descendre sous les services managés pour exploiter directement les API. Et j'ai découvert un écosystème entièrement nouveau avec Power BI et Fabric.

En posture, la différence avec la première année tient aux interlocuteurs. Chaque projet a mobilisé des acteurs extérieurs à l'équipe Cloud. Le comité d'architecture, devant lequel j'ai présenté et fait valider trois architectures conçues de bout en bout, m'a obligé à exposer non seulement la solution mais les alternatives écartées et les raisons de leur rejet. J'ai d'abord vu ça comme une formalité ; j'ai compris sa valeur en la pratiquant. Et le référent conformité m'a appris à distinguer faire et pouvoir prouver que l'on fait.

Côté enseignements, trois choses. On ne corrige que ce que l'on mesure : le dispositif conçu pour prouver la conformité a révélé une non-conformité que personne ne soupçonnait. La meilleure façon de fiabiliser un paramètre est de le supprimer. Et tout ne doit pas être automatisé : le choix d'un seuil, d'un périmètre, l'arbitrage entre construire et attendre, relèvent d'un jugement que rien ne remplace.

Cette année m'a moins appris à construire qu'à rendre durable ce qui est construit. C'est, je crois, le passage du statut d'exécutant technique à celui d'ingénieur responsable d'un périmètre.

08 — CONCLUSION

SLIDE 31 — Conclusion (1 min)

Quatre projets, quatre résultats concrets.

La supervision des sauvegardes est en production, validée en comité, répond à une mesure critique de l'ISO 27001, et a révélé des non-conformités qui font l'objet d'une refonte.

La gouvernance DNS est déployée au niveau du groupe : la règle ne vit plus dans le code de chaque projet mais dans la gouvernance de la plateforme, et une classe entière d'erreurs silencieuses a disparu.

La supervision des quotas est en production et couvre 21 fournisseurs, contre 3 pour la fonctionnalité native.

Et une passerelle Power BI a été déployée pour Digit-GI, et surtout documentée : d'un cas particulier réussi, le mécanisme est devenu une brique réutilisable.

Cette seconde année a confirmé mon souhait de poursuivre dans les métiers du Cloud et du DevOps. Et elle m'a donné une conviction qui dépasse ces projets : la valeur d'un travail d'infrastructure ne se mesure pas à ce qu'il fait fonctionner, mais à ce qu'il permet de garantir, et de transmettre.

SLIDE 32 — Merci (15 s)

Merci pour votre attention. Je suis à votre disposition pour vos questions.

Récapitulatif du minutage

Ce total fait un peu plus de 32 minutes lu mot à mot : c'est volontaire, un script se lit toujours plus lentement qu'il ne se dit. Si après deux répétitions chronométrées tu dépasses encore 25 minutes, coupe dans cet ordre : slide 21 (le paragraphe DCE/DCR), slide 24 (le paragraphe sur Fabric), slide 6 (le paragraphe IaC), slide 5 (les chiffres VINCI Construction). Ne coupe jamais dans les slides 10, 14, 17 et 28 : c'est là que se joue la note.