Pourquoi votre équipe d'ingénierie ralentit (même si vous continuez à embaucher)

Il y a quelques années, une équipe produit avec laquelle je travaillais comptait quinze ingénieurs. Ils livraient des fonctionnalités toutes les deux semaines. La direction a décidé de doubler l'effectif pour accélérer les livraisons. Six mois plus tard, avec trente ingénieurs, ils livraient toutes les trois semaines. Tout le monde était perplexe. Les ingénieurs n'étaient pas paresseux. Ils n'étaient pas moins compétents. Quelque chose d'invisible les ralentissait.

Cette chose invisible, c'est ce qu'on appelle aujourd'hui la charge cognitive. Et c'est la raison principale pour laquelle le platform engineering existe.

Le travail caché avant d'écrire du code

Imaginez que vous êtes développeur et qu'on vous confie une nouvelle fonctionnalité. Avant d'écrire une seule ligne de logique métier, vous devez :

• Créer un nouveau dépôt avec les bonnes règles de protection de branches
• Mettre en place un pipeline de build et un pipeline de test
• Configurer un environnement de développement connecté à une base de données de développement
• Comprendre comment déployer en staging
• Apprendre le processus de déploiement en production de l'entreprise
• Savoir comment effectuer un rollback en cas de problème
• Mettre en place la supervision et les logs pour votre service

Chacune de ces tâches nécessite un changement de contexte. Vous devez vous rappeler quel outil l'équipe utilise pour l'IC, quel fournisseur de cloud héberge l'environnement de staging, quelle version de base de données est compatible, et à qui demander l'accès à la production.

Pour un développeur qui veut se concentrer sur les fonctionnalités visibles par les utilisateurs, c'est épuisant. Et ce n'est pas une question de compétence. Même les ingénieurs seniors ralentissent lorsqu'ils doivent jongler entre les connaissances d'infrastructure et la logique métier.

Le vrai coût : la charge cognitive

La charge cognitive correspond à l'effort mental nécessaire pour accomplir une tâche. Quand vous écrivez une fonctionnalité, votre cerveau traite la logique métier, le flux de données, les cas limites. C'est déjà beaucoup. Ajoutez maintenant les commandes de déploiement, les variables d'environnement, la configuration des pipelines et les procédures de rollback. Votre cerveau doit répartir sa capacité entre deux domaines très différents.

Le résultat est prévisible : les fonctionnalités prennent plus de temps, les erreurs sont plus fréquentes, et les ingénieurs se sentent vidés en fin de journée. Pas parce qu'ils sont mauvais dans leur travail, mais parce qu'ils sont obligés de retenir trop de choses en même temps.

Ce problème s'aggrave à mesure que l'entreprise grandit. Une équipe de trois à cinq personnes peut partager ses connaissances de manière informelle. Tout le monde sait comment les autres déploient. Mais quand vous avez dix équipes produit, chacune avec ses préférences, le chaos se multiplie. Une équipe utilise Jenkins. Une autre utilise GitLab CI. Une troisième utilise GitHub Actions. Une équipe déploie directement en production. Une autre exige trois niveaux d'approbation manuelle. Une équipe utilise Kubernetes. Une autre utilise des machines virtuelles classiques.

L'équipe plateforme ou DevOps est alors submergée parce que chaque équipe a besoin d'aide avec une configuration différente. Et les équipes produit restent lentes parce qu'elles passent la moitié de leur temps sur l'infrastructure.

Le platform engineering n'est pas un outil de plus

C'est là que le platform engineering entre en jeu. Mais il est important de comprendre ce qu'il est et ce qu'il n'est pas.

Le platform engineering ne consiste pas à construire un tableau de bord sophistiqué ou à acheter un nouvel outil. C'est un changement de mentalité : l'infrastructure et les pipelines ne sont plus des projets secondaires que les équipes traitent quand elles ont le temps. Ils deviennent des produits internes qui doivent être conçus, construits et maintenus avec la même rigueur que les produits utilisés par vos clients.

L'idée centrale est simple : au lieu que chaque équipe construise son propre pipeline de zéro, l'équipe plateforme fournit un chemin prêt à l'emploi. Au lieu que chaque équipe apprenne à déployer en production, la plateforme fournit un mécanisme de déploiement testé et sûr. Les équipes produit se concentrent sur le code et les fonctionnalités. La plateforme gère la surcharge liée à l'infrastructure et aux pipelines.

Cela réduit considérablement la charge cognitive. Les développeurs n'ont plus besoin de se rappeler comment configurer les environnements, comment paramétrer la supervision ou comment gérer les rollbacks. La plateforme le fait. Ils écrivent simplement du code et exécutent le pipeline déjà en place.

Le piège du modèle unique

Mais c'est là que beaucoup d'initiatives de platform engineering échouent. Elles essaient d'imposer le même flux de travail à toutes les équipes. Cela ne fonctionne pas car les équipes ont des besoins différents. Certaines ont besoin de cycles de déploiement rapides. D'autres nécessitent des étapes d'approbation strictes. Certaines utilisent des bases de données ou des langages de programmation spécifiques qui demandent un traitement particulier.

Si la plateforme est trop rigide, les équipes la contourneront. Elles construiront leurs propres solutions de contournement, et vous revenez au problème initial d'infrastructure fragmentée et de charge cognitive élevée.

Une bonne plateforme s'adapte aux différences sans pousser les équipes à tout gérer elles-mêmes. Elle fournit un chemin standard qui couvre les cas courants, mais permet aux équipes de faire des choix là où c'est important. C'est là qu'intervient le concept de golden path, que nous explorerons en détail plus tard.

Ce que cela signifie pour votre équipe

Si votre équipe d'ingénierie grandit mais que la vitesse de livraison n'augmente pas, regardez le travail invisible. Demandez à vos développeurs : que devez-vous savoir ou faire avant de pouvoir commencer à écrire une fonctionnalité ? Les réponses vous indiqueront où la charge cognitive est la plus élevée.

L'objectif du platform engineering n'est pas de contrôler les équipes. C'est de supprimer les frictions qui les ralentissent. Bien fait, il permet aux développeurs de rester dans leur état de flow, de construire des fonctionnalités qui comptent, pendant que la plateforme gère le reste.

Liste de vérification pratique

Avant de commencer à construire une plateforme, posez-vous ces questions :

• Quelles tâches les développeurs répètent-ils pour chaque fonctionnalité ou service ?
• Quelles tâches d'infrastructure prennent le plus de temps à apprendre ou à dépanner ?
• Où les équipes créent-elles leurs propres solutions de contournement parce que le processus existant ne convient pas ?
• Que devrait savoir un développeur pour déployer un nouveau service de zéro aujourd'hui ?
• Quelles parties du pipeline causent le plus d'anxiété ou de retards lors des mises en production ?

Ce qu'il faut retenir

Votre équipe ne ralentit pas parce qu'elle est mauvaise dans son travail. Elle ralentit parce qu'elle porte un poids invisible. Le platform engineering consiste à retirer ce poids, pas à ajouter plus d'outils. Commencez par comprendre ce avec quoi vos développeurs luttent réellement, puis construisez le chemin qui fait disparaître ces difficultés.