Bienvenue dans un nouvel épisode des pépites de connaissances Microsoft sur M365FM, je suis votre autre Mirko Peters. Le sujet d'aujourd'hui est quelque chose dont presque tout le monde a entendu parler, mais que peu comprennent vraiment, l'ingénierie de plateforme. Vous avez probablement entendu parler du DevOps et l'idée que les développeurs et les équipes opérationnelles travaillent ensemble de manière fluide, mais cette promesse est compliquée en cours de route. Les développeurs ont fini par faire le travail des opérations et ceci d'emcéfonds. A la fin de cet épisode, vous comprendrez ce qui a mal tourné avec le DevOps, ce qu'est réellement une plateforme de développement interne, comment les golden paths qu'offrent aux équipes une voie claire à suivre et pourquoi les équipes d'ingénierie les plus intelligentes en construisent déjà une. Le désordre laissé par le DevOps ? Revenons à l'origine.

Le DevOps était une excellente idée avec un objectif simple, abattre les murs entre le développement et les opérations. Fini le code jeté par-dessus le mur en espérant que tout se passe bien. Déplacer les tests, la sécurité et les opérations plus tôt dans le processus. Livraison plus rapide, moins de transferts, responsabilités. Sur le papier, cela semblait parfait. Dans la pratique, quelque chose a mal tourné. Le Shift-Left-Left n'a pas seulement déplacé les responsabilités, il les a accumulées. Le développeur qui écrivait du code et ouvrait un ticket gère désormais l'infrastructure, la sécurité, le monitoring, Kubernetes, les pipelines séries CCD, la gestion des secrets et environ 15 services cloud dont il n'avait jamais entendu parler auparavant, dont il n'avait jamais entendu parler auparavant. Une seule personne gère tout cela tout en continuant à construire le produit réel. Voici à quoi cela ressemble dans la vraie vie.

Une équipe veut lancer un nouvel environnement pour tester une fonctionnalité. Avant le DevOps, ils envoyaient un ticket et attendaient. Après le DevOps, ils le gèrent eux-mêmes, ce qui semble génial en théorie, mais ils doivent maintenant écrire des modules Terraform, configurer un cluster Kubernetes, définir des règles réseau, connecter le monitoring, gérer les secrets et s'assurer que les politiques de sécurité sont appliquées et sont appliquées. Ce qui prenait une heure et quelqu'un d'autre sous forme de tickets prend désormais trois jours de travail à un développeur, trois jours durant lesquels il n'écrit pas de code produit. Il se bat avec des fichiers YAML et déborde la raison pour laquelle l'équilibreur de charge ne dirige pas correctement le trafic. La charge mentale est énorme ici. Chaque équipe finit par construire ses propres pipelines, scripts de déploiement et tableaux de bord de monitoring.

Et comme tout le monde est surmené, on prend des raccourcis. La sécurité est négligée parce que la date limite est vendredi. Les factures cloud doublent sans que personne ne le remarque car personne n'a pensé à arrêter l'environnement de test. Et quand quelque chose casse à 2h du matin, le développeur qui l'a construit est le seul à pouvoir le réparer. Mais pas viable et voici pourquoi c'est plus important que jamais. La complexité du cloud ne cesse de croire. Chaque année, il y a plus de services, plus d'outils et plus de décisions à prendre. Désormais, les outils de codage IA permettent aux développeurs de livrer du code plus vite que jamais. 10, 20, voire 30 fois plus de codes par jour. Mais tout ce code nécessite toujours une infrastructure de la sécurité et du monitoring. Plus de code sans un meilleur système signifie juste un chaos accéléré. Ah, si vous avez l'impression de vous noyer dans le YAML et Terraform, vous n'êtes pas seul.

Ce n'est pas un échec personnel. C'est systémique. Le modèle a brisé ce qu'est réellement l'ingénierie de plateforme. Alors quelle est la solution ? Cela s'appelle l'ingénierie de plateforme et voici la façon la plus simple d'y penser. Cette discipline crée une couche interne qui absorbe la complexité pour les développeurs. Imaginez que vous entrez dans un grand immeuble de bureau. Vous n'avez pas à vous soucier de qui a accès à quel étage, quel badge fonctionne ou où sont les sorties de secours. La réception s'occupe de tout cela pour vous et vous entrez simplement pour travailler. C'est exactement ce que l'ingénierie de plateforme fait pour vos développeurs. Plutôt que chaque développeur doive devenir un expert en Kubernetes, Terraform, réseau et sécurité et une équipe plateforme centrale, crée une couche qui gère toute cette complexité. Le développeur obtient une interface simple, clique sur un bouton, lance une commande, remplit un formulaire et la plateforme s'occupe de tout le reste.

Mais attention, ce n'est pas la même chose que le DevOps. Le DevOps demandait à chaque équipe de gérer sa propre infrastructure mais l'ingénierie de plateforme dit que c'est la recette de l'épuisement professionnel. A la place, l'équipe plateforme fournit des carreaux de pavéqueux, des méthodes standards, testées et sécurisées pour gérer les tâches courantes. Ils construisent et entretiennent la route tandis que les équipes produirent ou le simplement dessus. Le résultat principal de l'ingénierie de plateforme est ce qu'on appelle une plateforme interne de développeurs, IDP en abrégé. Considérez cela comme un système en libre-service qui automatise tout ce travail répétitif. Provisionnement d'infrastructures, pipelines, CICZD, contrôle de sécurité, monitoring, tout est intégré et standardisé. Voici un exemple concret. Lorsqu'un développeur veut déployer un nouveau service sans plateforme, il passe des jours à configurer l'infrastructure, écrire des pipelines et paramétrer le monitoring.

Avec une IDP, il clique simplement sur K, déployer Guimi dans une interface ou lance une commande et la plateforme gère tout, provisionnement, test, monitoring, déploiement, le tout en quelques minutes plutôt qu'en jours. Alors qu'est-ce que cela signifie pour vous ? Vous arrêtez d'être un touche à tout de l'infrastructure pour devenir un spécialiste de votre véritable produit. Votre travail consiste à nouveau à créer des fonctionnalités importantes pour vos clients plutôt que de déboguer pourquoi votre fichier d'état Terraform est corrompu. C'est tout l'intérêt. La plateforme interne de développeur expliquait simplement. Alors décomposons ce qu'est réellement une plateforme interne de développeur. C'est le moteur qui combine tout en un seul système, vos pipelines CICD, modèles d'infrastructure, politique de sécurité, monitoring et journalisation. Au lieu de 6 outils distincts que vous devez assembler, voici la logique.

Imaginez la différence entre cuisiner soi-même et utiliser un distributeur automatique. Cuisiner de zéro signifie acheter les ingrédients, couper les légumes, doser les épices, surveiller la cuisson. Beaucoup de décisions, beaucoup d'étapes, beaucoup de risques d'erreurs. Un distributeur automatique vous donne un résultat en appuyant sur un bouton. Moins de décisions, un résultat plus rapide, une qualité constante. Un IDP est ce distributeur automatique. Le développeur n'a pas besoin de savoir comment l'infrastructure est provisionnée ou où les secrets sont stockés. Il lui suffit d'appuyer sur le bouton. Que contient ce distributeur automatique ? Les composants principaux sont à ces standards. Des modèles CICD pour des builds cohérents, le provisionnement d'infrastructures pour créer des environnements, la gestion des secrets pour éviter les identifiants dans les fichiers de configuration et une journalisation avec observabilité intégrée pour dépanner sans paniquer.

Le tout préconfiguré, testé et maintenu par l'équipe plateforme. Voici un exemple concret. Un développeur tape créer, nouveau service qu'il y a dans une ligne de commande ou clique sur un bouton dans un portail. En coulisses, l'IDP crée un nouveau dépôt avec la bonne structure, configure un pipeline de build qui exécute les tests automatiquement, déploie le service dans un environnement de développement et ajoute des points de contrôle de santé avec journalisation. Tout cela se fait en quelques minutes. Le développeur n'a jamais touché à un fichier Terraform ni configuré à manifeste Kubernetes. Il a juste tapé une commande et obtenu un service opérationnel. Pourquoi est-ce important ? La cohérence est la raison principale quand chaque équipe construit ses propres pipelines et écrit ses propres scripts de déploiement, vous retrouvez avec des configurations uniques et regérables. 50 services différents, 50 façons de faire différentes.

Quand quelque chose casse, personne ne peut déboguer à part la personne qui la construit. Et si cette personne a quitté l'entreprise, bon courage. Un IDP élimine cela en faisant en sorte que chaque service suive les mêmes modèles, que chaque déploiement utilise le même pipeline et que chaque équipe bénéficie des mêmes valeurs par défaut. Quand quelque chose casse, les modèles sont familiers et la correction est documentée. Alors voici ce que cela signifie pour vous. Si votre organisation a 50 équipes faisant des déploiements de 50 manières différentes, un IDP est la solution. Cela ne signifie pas que les équipes perdent leur auto. Cela signifie que les tâches ennuyeuses, répétitives et sujettes aux erreurs sont standardisées pour que le travail créatif et intéressant puisse varier. C'est un compromis qui en vaut la peine. Golden Path est que le chemin à suivre, pas une cage. Parlons des Golden Path 2.

Vous avez probablement déjà entendu ce terme, mais l'idée est simple. Un Golden Path est un flux de travail recommandé et préconstruit qui rend la bonne pratique la plus facile à adopter. Votre équipe plateforme vous dit, voici comment nous vous suggérons de procéder. Nous l'avons testé, ça fonctionne, et nous vous soutiendrons en cas de problème. Notez bien le mot, car ils suggérons, eux. Les Golden Paths que me sont pas obligatoires. Les développeurs peuvent quitter le chemin si nécessaire, mais ce chemin reste l'option par défaut, rapide et sûr. Il est déjà opérationnel, pris en charge et documenté. Vous n'avez pas besoin de tout inventer à partir de zéro. Imaginez-les comme des rails plutôt que comme des garde-fous. Les garde-fous vous rattrapent quand vous percutez quelque chose. Ils réagissent, vous empêchent de tomber dans le fossé et ne vous aide pas à diriger. Les rails vous guident en douceur le long du parcours sans que vous ayez à choisir votre direction.

Les Golden Paths que ce sont les rails. Ils vous font avancer, ils ne se contentent pas de vous rattraper en cas d'échec. C'est là que beaucoup d'équipes se trompent. Elles conçoivent les Golden Paths que pour l'équipe plateforme, pas pour les développeurs. Elles privilégient la pureté architecturale, la conformité sécuritaire ou des règles internes que personne en dehors de l'équipe ne comprend. Le résultat est brillant sur un tableau blanc, mais horrible à utiliser. Les développeurs trouvent discrètement des solutions de contournement, l'adoption chute et l'équipe plateforme se demande pourquoi personne n'apprécie leurs efforts. La solution est simple mais difficile à mettre en œuvre. Vous avez besoin de portes de sortie. Si le chemin ne correspond pas au cas d'usage d'un développeur, il doit pouvoir en sortir. Un moyen de remplacer une valeur par défaut, d'apporter son propre pipeline ou de sortir complètement de la plateforme.

Et voici le point important. Quand il quitte le chemin, ce n'est pas un échec, c'est un retour d'information. Chaque fois qu'un développeur quitte le Golden Paths avec Jules, cela vous apprend quelque chose de concret. Soit il manque une fonctionnalité essentielle, soit le cas d'usage n'a réellement pas sa place ici. Ces deux signaux sont précieux. En pratique, un bon Golden Paths qui ressemble à ceci. Une équipe veut déployer un nouveau service back. Elle utilise le chemin. Il lui fournit un dépôt modèle avec la bonne structure, un pipeline CICD standard, déjà testé une journalisation et un monitoring intégré et un retour arrière en un clic en cas de problème. Tout cela prend des minutes au lieu de jour et comme l'équipe plateforme maintient le chemin, elle répare les éventuels problèmes. Le développeur n'a pas besoin de devenir un expert en débogage de pipeline. Ce que cela signifie pour vous, moins de surprise.

Vous livrez plus vite car le chemin est testé. Vous livrez plus sûrement car la sécurité et le monitoring sont intégrés. Vous livrez avec confiance car le retour arrière se fait en un clic. Le chemin est là pour vous aider, pas pour vous freiner. Utilisez-le. Réduire la charge cognitive. C'est là que le bénéfice réel apparaît. Quand une plateforme gère le gros du travail, les développeurs peuvent vraiment se concentrer sur le code. Ils n'ont pas besoin de savoir quelle version de Kubernetes est utilisée. Ils n'ont pas à mettre à jour les modules Terraform à chaque changement d'API d'un fournisseur cloud. Ils se contentent de créer des fonctionnalités. Les ingénieurs plateformes absorbent cette complexité. Ils décident ce que les développeurs doivent voir et ce qui doit rester masqué. C'est un véritable choix de conception, pas seulement une décision technique. Il s'agit de déterminer quels détails importants pour l'utilisateur de la plateforme et lesquels ne sont que du bruit.

Voici un exemple concret. Un développeur qui déploie un nouveau service se moque des tailles de notre cluster, des types d'instances ou des seuils d'auto-scaling. Ce qui lui importe, c'est que son service tourne et qu'il réponde rapidement. La plateforme préconfigure donc tout cela en fonction du niveau de l'application. Petit service, voici la configuration adaptée. Service à fort trafic, voici une configuration différente. Le développeur ne fait pas ses choix car il n'en a pas besoin. Pourquoi est-ce important ? Parce que le risque de burn-out diminue quand les développeurs n'ont pas à jongler avec 15 préoccupations à la fois. Certaines équipes plateformes matures ont réduit la charge cognitive de près de moitié. 40 à 50% de charge mentale en moins. C'est un changement majeur. C'est la différence entre quitter le travail avec encore de l'énergie et fixer un terminal à 22h en se demandant pourquoi son pipeline a échoué.

Mais attention à ce point. Ne créez pas d'illusions. Certaines équipes plateformes tombent dans un piège. Elles masquent des paramètres sans donner aux développeurs les moyens de comprendre ce qui se passe en coulisses. Ce n'est pas de l'abstraction, c'est de la tromperie et cela se retourne contre vous dès qu'un problème survient. Les développeurs se heurtent à un mur et la plateforme devient soudain une boîte noire qui travaille contre eux. On appelle cela une abstraction imparfaite. Vous masquez la complexité mais celle-ci finit toujours par refaire surface. Une base de données ralentit, un déploiement échoue, une règle de sécurité bloque quelque chose d'inattendu. Et le développeur n'a aucun modèle mental de ce qui se passe car la plateforme ne lui en a jamais fourni. La transparence est essentielle. Montrez aux développeurs ce qu'ils doivent savoir au moment où ils en ont besoin. Ne vous contentez pas de tout cacher en espérant que tout se passe bien.

Pour vous cela signifie moins de changement de contexte et plus d'état de flow. Vous ne commencez pas votre journée en vous demandant si le cluster Kubernetes a besoin d'une mise à jour. Vous commencez en travaillant sur la fonctionnalité attendue la semaine prochaine. Votre métier redevient votre travail réel. Traitez la plateforme comme un produit. Aujourd'hui nous parlons de ce qui change la manière dont les outils internes fonctionnent vraiment. La plupart des gens pensent qu'une équipe plateforme n'est qu'une équipe infrastructure. Ce n'est pas le cas. Une équipe plateforme est une équipe produit et les développeurs utilisant cette plateforme sont leurs clients, pas des personnes qui ouvrent des tickets. Cela change tout. Une équipe produit échange avec ses clients, identifie les véritables points de douleur, priorise les fonctionnalités selon les besoins réels, mesure l'adoption. Elle ne construit pas pour ensuite abandonner, elle itère continuellement.

Alors à quoi ressemble une équipe produit dans la pratique ? Elle ne fonctionne pas comme un service d'assistance. Un développeur ouvre un ticket et l'équipe plateforme s'en occupe manuellement. Mais pas du plateforme engineering, c'est juste des opérations centralisées sous un nouveau nom. Ça ne passe pas à l'échelle, ça ne réduit pas la charge cognitive, ça déplace juste le goulot d'étranglement d'une équipe à l'autre. Voici ce qu'ils font à la place. Ils mesurent les indicateurs pertinents. Tant jusqu'au premier déploiement. Vitesse d'intégration des nouveaux membres. Score de satisfaction des développeurs. Ce sont ces mesures qui vous disent si la plateforme aide réellement les gens ou si elle ajoute juste une couche de complexité. Petit file est un bon exemple. Leur équipe plateforme fonctionne comme une véritable organisation produit. Ils ont des roadmap, des hookers et ils discutent avec les développeurs de ce qui fonctionne ou non.

Ils considèrent la plateforme comme un produit qui doit mériter son adoption chaque jour et c'est là l'idée maîtresse. Une plateforme que personne n'utilise, mais qu'un projet qui prend la poussière dans un coin. L'adoption est la validation ultime. Si les développeurs choisissent votre plateforme plutôt que de créer leurs propres outils, vous avez réussi. S'ils l'évitent, aucune excellence technique ne pourra y remédier. Qu'est-ce que cela signifie pour vous ? Cela signifie que si vous construisez une plateforme, ne commencez pas par des diagrammes d'architecture, ni par des clusters Kubernetes ou des modules Terraform. Commencez par des entretiens utilisateurs. Parlez aux développeurs qui l'utiliseront. Découvrez ce qui est réellement pénible. Construisez une chose qui résout un vrai problème, puis itérez. C'est ainsi que l'on construit quelque chose que les gens veulent vraiment utiliser.

Pourquoi maintenant, la vague de l'IA ? Alors pourquoi en parlons-nous en ce moment précis ? Pourquoi pas il y a 5 ans ? La réponse est l'IA. Les outils de codage par IA, comme GitHub Copilot, permettent aux développeurs de publier du code à une vitesse inédite à inédite. 10 voire 20 fois plus de code par jour qu'il y a seulement quelques années, 5 années. Cela semble incroyable. Et ça l'est. Mais il y a un piège. Tout ce code a toujours besoin d'infrastructure. Il a toujours besoin de sécurité. Il doit toujours être déployé, testé et opéré. Plus de code sans un meilleur système ne vous rend pas plus rapide. Cela rend juste le chaos plus rapide. Si vos développeurs se noient déjà sous le YAML et Terraform, l'IA ne réglera pas cela. Cela signifie simplement qu'ils se noieront plus vite tout en produisant plus de code à maintenir. A l'heure actuelle, environ 55% des entreprises ont déjà adopté l'ingénierie de plateforme sous une forme ou une autre.

Gartner prévoit que ce chiffre atteindra 80% en ici fin 2026. Ce n'est pas une tendance lente. Un changement qui se produit en ce moment même. Les entreprises réalisent qu'elles ne peuvent pas faire évoluer leurs équipes d'ingénierie sans une couche de plateforme. L'ancienne approche où chaque équipe fait tout elle-même ne fonctionne plus lorsque l'on déploie du code à la vitesse de l'IA. Voici ce que beaucoup de gens oublient. L'IA ne crée pas seulement le besoin de plateforme, elle aide aussi à les construire. Les équipes de plateforme utilisent l'IA pour générer des modules Terraform, rédiger la documentation et déboguer les pipelines. La technologie qui crée l'urgence fournit également les outils pour y répondre. Un mot de prudence cependant, l'IA amplifie tout ce que vous avez déjà. Si vos bases sont solides, avec une bonne architecture et une plateforme bien conçue, l'IA multiplie votre productivité par deux ou trois.

Mais si vos fondations sont faibles, l'IA vous aide simplement à faire de plus grosses erreurs plus rapidement. Mauvaise configuration, faille de sécurité, infrastructure défaillante, tout est envoyé en production avant que quelqu'un ne s'en aperçois. L'IA ne corrige pas les mauvaises fondations, elle les expose. Voici un exemple concret. Une entreprise disposant d'une bonne plateforme de développement interne peut permettre à un non-ingénieur de déployer des outils d'IA en toute sécurité. La plateforme fournit des garde-fous. Elle applique des politiques de sécurité. Elle gère l'infrastructure. Ainsi, un chef de produit peut lancer un prototype basé sur l'IA sans avoir besoin de comprendre Kubernetes ou le réseau cloud. C'est puissant. C'est ce genre de choses qui distinguent les équipes prêtes pour l'ère de l'IA de celles qui vont être laissées pour compte. Qu'est-ce que cela signifie pour vous ? La fenêtre pour construire une plateforme se refaire.

Non pas parce que la technologie disparaît, mais parce que l'écart entre les équipes avec et sans plateforme se creuse rapidement. Chaque mois d'attente permet aux équipes ayant déjà une plateforme de prendre encore plus d'avance. Elles livrent plus vite, s'épuisent moins et s'adaptent plus rapidement aux nouveaux outils. Les équipes sans plateforme prennent de plus en plus de retard. Le choix vous appartient. Commencez par un cachemin d'horicolène. Alors par où commencer concrètement ? Si vous pensez devoir construire une plateforme de développement interne complète à partir de zéro, arrêtez. C'est le moyen le plus rapide de tuer votre projet avant même qu'il ne commence. La plus grande erreur des équipes est de vouloir tout construire en même temps. Elle passe des mois à concevoir la plateforme parfaite en y accumulant toutes les fonctionnalités imaginables. Ensuite, elle la lance et rien ne se passe. Personne ne l'utilise. Pourquoi ?

Parce qu'elle résout des problèmes dont personne ne se soucie et qu'il faut lire un manuel pour simplement commencer. Le conseil est simple. Ne faites pas cela. Commencez plutôt petit. Parlez vraiment aux développeurs, pas aux architectes, pas aux managers et ne vous fiez pas à vos propres suppositions. Trouvez les personnes qui écrivent des fonctionnalités au quotidien. Demandez-leur ce qui leur pose problème. Identifiez le flux de travail qui prend le plus de temps, frustre le plus de monde ou qui est trop souvent ignoré. Ensuite, construisez un golden passeuil complet de bout en bout. Peut-être s'agit-il de créer et déployer un nouveau microservice. Peut-être est-ce configuré un environnement de développement depuis zéro. Ou peut-être déployer un correctif en production sans rien casser. Choisissez celui qui fait le plus souffrir et créez un chemin qui fait disparaître cette douleur. Construisez-le, testez-le avec de vrais utilisateurs, récoltez les retours, itérez.

Ajoutez ensuite un autre chemin puis un autre encore. N'essayez pas de résoudre tous les problèmes à la fois. Résolvez un problème vraiment bien et laissez l'élan vous porter vers l'avant. Comment savoir si cela fonctionne ? Mesurez les bonnes choses. Le temps entre l'idée et le déploiement, le nombre d'étapes manuelles éliminées et les taux d'adoption volontaires. Si les développeurs préfèrent votre chemin à la création du leur, vous avez gagné. S'ils l'évitent, écoutez-les et changez de direction. Voici le piège à éviter. Ne rendez pas la plateforme obligatoire. Forcez les développeurs à suivre votre chemin et ils finiront par le rejet. Ils trouveront des moyens de le contourner. Ils créeront leurs propres scripts et vous les cacheront. Au contraire, rendez le chemin facile. Rendez-le plus rapide que l'alternative. Faites-en le choix évident mais jamais le seul choix. Le premier chemin est toujours le plus difficile. Il vous apprend tout sur la réflexion produit.

Vous apprenez à parler aux utilisateurs à prioriser et que construire ce que les gens veulent vraiment est bien plus dur que construire quelque chose qui fonctionne. Une fois que vous l'avez fait, le deuxième chemin est plus simple et le troisième. Encore plus, vous ne construisez pas une plateforme en une seule fois. Vous la construisez à un chemin à la fois. Voilà, c'est ça le système. L'ingénierie de plateforme consiste à construire une route goudronnée pour que les développeurs se concentrent sur la conduite plutôt que de boucher des nids de poules. Si vous en avez assez de lutter avec l'infrastructure, commencez par trouver un seul Golden Path au sein de votre équipe, juste un. Partagez ceci avec quelqu'un qui a besoin de l'entendre et abonnez-vous pour plus d'analyses comme celle-ci. C'est parti !