« You build it, you run it. » Le mantra du DevOps a libéré les équipes en leur confiant la responsabilité de bout en bout de leurs services. Mais il a aussi créé un effet de bord pervers : on demande désormais à chaque développeur de maîtriser l’orchestration, le réseau, la sécurité, l’observabilité et toute la chaîne de déploiement. La charge cognitive est devenue écrasante. L’ingénierie de plateforme (platform engineering) propose une troisième voie.

Le retour de bâton du « tout le monde fait tout »

Confier l’intégralité de l’infrastructure à des équipes produit déjà sous pression revient souvent à ralentir tout le monde. Chacun réinvente sa propre tuyauterie, les pratiques divergent d’une équipe à l’autre, la sécurité devient inégale, et les meilleurs ingénieurs passent plus de temps à se battre avec l’outillage qu’à livrer de la valeur métier.

Le cloisonnement classique, avec une équipe Ops centrale qui valide tout, n’est pas une solution non plus : il recrée exactement le goulot d’étranglement que le DevOps voulait supprimer. Entre l’anarchie et le ticket bloquant, il fallait une voie intermédiaire.

La plateforme interne comme produit

L’idée est de constituer une petite équipe dédiée qui construit et exploite une plateforme de développement interne. Cette plateforme n’est pas un comité de validation, c’est un produit, avec ses utilisateurs (les développeurs) et une vraie exigence d’expérience.

Son but : offrir des chemins balisés, c’est-à-dire des parcours par défaut, sûrs et documentés, pour les tâches les plus courantes. Créer un nouveau service, provisionner une base de données, déployer en production : tout cela doit se faire en libre-service, en quelques minutes, sans ouvrir un ticket et sans attendre une autre équipe.

Ce que la plateforme prend en charge

  • Le provisionnement d’infrastructure standardisé, via des modèles validés et réutilisables.
  • Les chaînes de construction et de déploiement préconfigurées et éprouvées.
  • L’observabilité intégrée par défaut : métriques, journaux et traces sans configuration manuelle.
  • Les règles de sécurité et de conformité appliquées automatiquement, en arrière-plan, sans que le développeur ait à y penser.

Le développeur garde son autonomie et sa rapidité, mais il n’a plus à tout comprendre du socle technique. La complexité est encapsulée, pas supprimée : quelqu’un s’en occupe, une bonne fois, pour tout le monde.

Mesurer le succès

Le bon indicateur de réussite n’est pas le nombre d’outils déployés ni la sophistication de la plateforme, mais des mesures concrètes d’expérience développeur : le temps qu’il faut à un nouvel arrivant pour mettre son premier changement en production, la fréquence des déploiements, le délai entre une idée et sa mise en ligne. Si ce délai se compte en heures plutôt qu’en semaines, la plateforme remplit son rôle.

Un équilibre, pas une mode

L’ingénierie de plateforme ne signe pas la mort du DevOps, elle le rend soutenable à grande échelle. Attention toutefois à un piège majeur : une plateforme imposée d’en haut, sans écouter ses utilisateurs, devient une couche de friction supplémentaire que les équipes contournent. La règle d’or reste de la traiter comme un produit, avec des retours réguliers, une documentation soignée et une adoption volontaire. Une plateforme qu’on subit a échoué ; une plateforme qu’on choisit a réussi.