Ingénierie de plateforme : pourquoi votre équipe n'en a pas encore besoin

La prédiction de Gartner semble alarmante :80 % des organisations de génie logiciel créeront des équipes de plateforme d’ici 2026. Cette statistique a convaincu hier une vague de startups de 15 personnes dont elles avaient besoin d’une plate-forme de développement interne (IDP). Ils ont tort. Et cette erreur leur coûtera plus de 12 mois de temps d’ingénierie qu’ils ne peuvent pas se permettre de perdre.

L’ingénierie des plateformes résout un vrai problème. À grande échelle, les développeurs se noient dans la complexité de l’infrastructure. Ils consacrent 30 à 40 % de leur temps aux pipelines de déploiement, à la configuration de l'environnement et aux tâches opérationnelles au lieu d'écrire du code produit. Une forte personne déplacée récupère cette époque. Mais le mot clé està grande échelle.

Les efforts pour créer et maintenir une plate-forme ne diminuent pas. Cela prend la même équipe, les mêmes mois et le même budget, que votre organisation compte 100 développeurs ou 1 000. Le calcul du retour sur investissement ne fonctionne que lorsque vous répartissez ce coût fixe entre suffisamment d'ingénieurs. Pour la plupart des startups, ce seuil se situe à50+ développeurs.

Ce que l’ingénierie de plateforme résout (à la bonne échelle)

Une plateforme de développement interne est une couche en libre-service située entre vos développeurs et votre infrastructure. Au lieu que chaque ingénieur apprenne les politiques Kubernetes, Terraform et AWS IAM, il interagit avec une interface simplifiée : cliquez sur un bouton pour lancer un environnement de test, sélectionnez un modèle pour déployer un nouveau microservice ou déclenchez une restauration à partir d'un tableau de bord.

La proposition de valeur est claire. Rapport des organisations avec des personnes déplacéesCoûts du cloud réduits de 28 %en moyenne, et les implémentations matures montrent185 à 220 % de retour sur investissement en 18 à 24 mois. Stripe a construit sa plateforme interne très tôt et a réussiMise à l'échelle 3 fois plus rapidelorsqu'il est passé de 50 à 500 ingénieurs. Ces chiffres sont réels.

Ils sont également trompeurs si vous êtes une startup comptant 12 ingénieurs.

Stripe comptait plus de 50 ingénieurs lorsque l'investissement dans la plateforme a commencé à porter ses fruits. Les économies de 28 % sur le cloud s'appliquent aux organisations dépensant plus de 50 000 $/mois en infrastructure, et non 500 $/mois. Le retour sur investissement de 185 à 220 % suppose que vous disposez de suffisamment de développeurs générant suffisamment de demandes d'infrastructure pour justifier une équipe de plateforme dédiée. Deux ingénieurs gérant les déploiements de huit autres ingénieurs sont une équation différente de deux ingénieurs gérant les déploiements de 200 personnes.

Le coût de l’ingénierie de plateforme, quelle que soit la taille de l’équipe

Il existe trois voies pour obtenir un IDP : des outils SaaS (assembler des services hébergés), une plate-forme commerciale (acheter un IDP prêt à l'emploi) ou la création d'une plate-forme personnalisée en interne. Les coûts diffèrent énormément.

Le modèle est évident. Une plate-forme personnalisée coûte entre 4 000 et 8 000 $ par développeur et par mois pour une équipe de 10 personnes. Pour 200 développeurs, cela tombe entre 400 et 800 dollars. Le coût fixe d'une équipe de plate-forme (3 à 5 ingénieurs senior gagnant entre 150 000 et 250 000 $ chacun) reste à peu près le même. Vous répartissez entre 500 000 et 1,2 million de dollars de salaires annuels entre vos effectifs. Sur 10 développeurs, chacun supporte entre 50 000 et 120 000 $ de ce fardeau. À 200, c'est entre 2 500 et 6 000 dollars par personne.

Les PDI commerciaux comme Humanitec, Cortex et Port commencent à999 $/moiset échelle avec le nombre de sièges. Pour une équipe de 10 personnes, vous payez entre 100 et 250 $ par développeur et par mois pour des outils qui résolvent des problèmes que votre équipe n'a pas encore. Pour une organisation de 200 personnes, le même coût par siège permet un gain de temps mesurable pour suffisamment d'ingénieurs pour justifier la dépense.

Pourquoi les startups adoptent trop tôt l’ingénierie de plateforme

Trois forces poussent les startups vers un investissement prématuré dans les plateformes.

Le battage médiatique de Gartner crée une urgence là où il n’y en a pas

La prévision « 80 % des organisations d’ici 2026 » se lit comme un mandat. Les CTO craignent de prendre du retard. Mais l’échantillon de Gartner se concentre sur les entreprises comptant plus de 500 développeurs. La même prédiction appliquée à votre équipe d’ingénieurs de 20 personnes est comme une lecture dans une boulangerie du coin : 80 % des entreprises alimentaires adopteront l’automatisation des entrepôts. La technologie fonctionne. Cela n'a aucune importance à votre échelle.

Les conférences présentent de mauvais exemples

Chaque conférence sur l'ingénierie de plate-forme à la KubeCon présente des entreprises comme Spotify, Stripe ou Shopify. Ces entreprises disposent de plus de 500 à 2 000 ingénieurs et de budgets d’infrastructure de plusieurs millions de dollars. Leurs équipes de plate-forme ont du sens car l'alternative est de 500 ingénieurs déterminer de manière indépendante comment déployer sur Kubernetes. Votre startup n'a pas ce problème. Votre startup compte 8 ingénieurs qui travaillent tous sur le même canal Slack.

Les fournisseurs d'outillage vendent à de petites équipes qui n'ont pas besoin de leur produit

Les fournisseurs commerciaux d’IDP s’adressent à des équipes de toutes tailles. Leurs pages de tarification affichent un forfait « Starter » à 999 $/mois. Ce plan existe pour attirer des acheteurs ambitieux ; CTO qui souhaitent la sophistication d'une équipe de plateforme sans les effectifs. En pratique, une équipe de 10 personnes utilisant un IDP commercial passe plus de temps à configurer la plateforme qu'elle n'en gagne à l'utiliser. Le gain de productivité est négatif pendant les 3 à 6 premiers mois d'intégration.

Ce qui fonctionne à la place : l'échelle DevOps-plateforme

L’ingénierie de plateforme n’est pas un choix binaire. C'est un spectre. Et votre position sur ce spectre doit correspondre à la taille de votre équipe, et non à votre ambition.

2 à 10 ingénieurs : outils SaaS et scripts partagés

À cette taille, chaque ingénieur connaît chaque partie de la pile. Vous n'avez pas besoin d'un portail libre-service car votre « portail » est une conversation de 5 minutes dans Slack. Votre pile d'infrastructure devrait ressembler à ceci :

• CI/CD.Actions GitHubavec 3 à 5 workflows couvrant le lint, le test, la construction et le déploiement. Le niveau gratuit gère la plupart des startups.
• Déploiements.Vercel, Railway ou Fly.ioavec les déploiements git-push. 0 $ à 50 $/mois.
• Infrastructure en tant que code.Terraform ou Pulumi avec un backend à état partagé. Un ingénieur gère les configurations ; d'autres les utilisent.
• Surveillance.Niveau gratuit Datadog, Grafana Cloud ou Sentry. 0 $ à 100 $/mois.
• Scripts partagés.Un répertoire /scripts dans votre dépôt avec des scripts shell pour les tâches courantes. Zéro coût, zéro frais de maintenance.

Coût total :0 $ à 500 $/mois. Temps d'installation : 1 à 2 semaines. Effectif dédié : zéro (un ingénieur consacre 10 à 20 % de son temps à l'infrastructure).

10 à 50 ingénieurs : pratiques DevOps avec automatisation légère

C’est à ce stade que l’infrastructure commence à consommer du temps réel. Les nouvelles recrues mettent 2 à 3 jours pour faire fonctionner leur environnement de développement. La configuration de l’environnement de test nécessite l’aide d’un ingénieur senior. Les équipes attendent des heures pour les environnements partagés. Mais le correctif n’est pas une équipe de plateforme. C'est mieux DevOps.

• Modèles d'environnement.Fichiers Docker Compose ou flocons Nix qui font tourner la pile complète localement en une seule commande.
• Mise en scène en libre-service.Une action GitHub qui déploie un PR sur une URL intermédiaire isolée. Vercel le fait par défaut ; pour les services backend, utilisez les espaces de noms Kubernetes ou les environnements ferroviaires.
• Modules d'infrastructures.Modules Terraform réutilisables pour les modèles courants (nouveau microservice, nouvelle base de données, nouvelle file d'attente). Les ingénieurs copient un module et remplissent des variables au lieu d'écrire du code infra à partir de zéro.
• 1-2 ingénieurs DevOps.Des personnes dédiées qui maintiennent les pipelines CI/CD, gèrent l’infrastructure et aident les équipes à résoudre les problèmes de déploiement. Il ne s'agit pas d'une « équipe de plate-forme », mais d'ingénieurs dont la responsabilité principale est de posséder l'infrastructure.

Coût total :500 $ à 3 000 $/moisen outillage, plus 1 à 2 salaires DevOps. Temps d'installation : 1 à 3 mois pour l'automatisation initiale. Cette approche gère la plupart des organisations d'ingénierie jusqu'à ce qu'elles atteignent 50 développeurs.

50+ ingénieurs : le temps d’une équipe plateforme

À 50 développeurs, les calculs changent. Vos 2 ingénieurs DevOps passent toute leur semaine à répondre aux demandes d'infrastructure. Le déploiement d'un nouveau service prend 3 jours au lieu de 3 heures. Les équipes dupliquent les modèles d'infrastructure car il n'existe aucun moyen standardisé de provisionner les ressources. L'intégration d'un nouvel ingénieur prend une semaine complète.

Désormais, une équipe de plateforme a du sens. Le2 à 5x le retour sur investissement en 18 à 24 moisentre en jeu parce que vous multipliez les gains de productivité chez plus de 50 ingénieurs. Un portail en libre-service pour les développeurs qui permet à chaque ingénieur de gagner 2 heures/semaine, ce qui permet à votre organisation de gagner plus de 100 heures/semaine. C'estProduction de 2,5 ingénieurs à temps pleinrécupéré, chaque semaine, de façon permanente.

C’est à ce moment-là que vous évaluez les IDP commerciaux ou que vous commencez à créer une plate-forme personnalisée. Les deux options ont désormais un chemin de retour sur investissement clair, car les coûts fixes se répartissent sur suffisamment d'effectifs pour justifier l'investissement.

Les barrières à l’adoption dont personne ne parle

Même avec la bonne taille d’équipe, l’ingénierie de plate-forme entraîne des frictions que le marketing des fournisseurs passe sous silence.

Les ingénieurs de plateforme qualifiés sont rares.Le vivier de talents pour les ingénieurs qui comprennent à la fois l’expérience en matière d’infrastructure et de développeur est restreint. Embaucher une équipe de plateforme composée de 3 à 5 ingénieurs signifie rivaliser avec les grandes entreprises technologiques pour les mêmes candidats. Les salaires des ingénieurs de plate-forme senior commencent entre 180 000 et 250 000 dollars aux États-Unis, et entre 120 000 et 180 000 dollars en Europe. Le recrutement seul peut prendre de 6 à 9 mois.

La migration n'est pas gratuite.Adopter un IDP commercial signifie migrer vos pipelines CI/CD existants, vos processus de déploiement et votre configuration de surveillance vers un nouveau système. Pour une équipe disposant de plus de 50 services, cette migration prend 3 à 6 mois et introduit un risque pour chaque service qu'elle touche.

L’adhésion de l’organisation nécessite des preuves.Les développeurs hésitent à changer d'outil à moins que la nouvelle plate-forme ne soit plus rapide et plus simple que celle qu'ils utilisent déjà. Un IDP qui ajoute des étapes au processus de déploiement sera confronté à des refus, quels que soient ses avantages à long terme. Vous avez besoin de champions internes, de déploiements progressifs et de victoires mesurables au cours des 90 premiers jours.

Le cadre décisionnel : avez-vous besoin d’une équipe plateforme ?

Posez ces cinq questions. Si vous répondez « oui » à trois questions ou plus, commencez à évaluer l’ingénierie de la plateforme. Sinon, restez fidèle aux outils SaaS et DevOps.

• Avez-vous plus de 50 développeurs ?En dessous de ce seuil, le coût par développeur d’une équipe plateforme dépasse les gains de productivité.
• Les développeurs consacrent-ils plus de 30 % de leur temps à l'infrastructure ?Si vos ingénieurs livrent des fonctionnalités 70 % du temps, DevOps fonctionne. S'ils passent la moitié de leur semaine sur les problèmes de déploiement, de surveillance et de configuration de l'environnement, quelque chose doit changer.
• Le déploiement d'un nouveau service prend-il plus de 2 jours ?Dans une configuration DevOps qui fonctionne bien, la création d'un nouveau microservice prend des heures. Si cela prend des jours, vos processus d'infrastructure ne s'adaptent pas à votre équipe.
• L'intégration d'un nouvel ingénieur prend-elle plus de 5 jours ?Les longs délais d'intégration indiquent que votre environnement de développement est trop complexe pour une configuration en libre-service avec uniquement de la documentation.
• Votre facture cloud est-elle supérieure à 50 000 $/mois ?En dessous de ce chiffre, la réduction des coûts de 28 % résultant de la standardisation de la plateforme permet d'économiser moins que le coût de l'équipe de la plateforme elle-même.

La plupart des startups répondent « oui » à zéro ou à une de ces questions. Et c'est très bien. Cela signifie que votre configuration actuelle fonctionne. Ne réparez pas une infrastructure qui n’est pas cassée.

Que faire maintenant si vous avez moins de 50 ingénieurs

Évitez la plateforme. Investissez dans les fondations qui faciliteront l’adoption future d’une plateforme.

• Standardisez votrePipelines CI/CD.Chaque dépôt doit utiliser la même structure de pipeline. L’adoption future de la plateforme consiste donc à regrouper les pipelines existants dans une couche libre-service, et non à les réécrire.
• Utilisez l’infrastructure comme code dès le premier jour.Les configurations Terraform ou Pulumi sont enregistrées dans le contrôle de version. Lorsque vous êtes prêt à adopter une plateforme, votre IaC devient la base sur laquelle elle s'appuie.
• Documentez votredécisions d'architecture.Les ADR (Architecture Decision Records) de votre dépôt expliquent pourquoi vous avez choisi des outils et des modèles spécifiques. Une future équipe de plateforme les utilise pour comprendre les contraintes avec lesquelles elles doivent travailler.
• Gardez votre nombre de services bas.Chaque nouveau microservice ajoute ultérieurement de la complexité à la plateforme. Si votre équipe n’a pas besoin de diviser un service, ne le divisez pas. UNmonolithe bien structuréavec des limites de modules claires, il est plus facile de mettre en place une plateforme que 15 microservices mal délimités.

Chez Savi, nous établissons ces fondations pour chaque produit que nous construisons. Chaque projet est livré avec un CI/CD standardisé, une infrastructure en tant que code et une automatisation du déploiement dès le premier jour. Nos ingénieurs seniors (1 à 2 par projet) possèdent la pile complète, y compris l'infrastructure, il n'y a donc pas de transfert vers une équipe DevOps distincte. Lorsque l’équipe d’ingénierie d’un client dépasse les 50 personnes, elle dispose de bases solides sur lesquelles construire une plate-forme. Ils n’héritent pas d’un enchevêtrement de processus manuels et de connaissances tribales.

L'essentiel

L’ingénierie de plateforme est une véritable discipline qui offre un retour sur investissement mesurable. À la bonne échelle. Pour les bonnes équipes. Au bon moment.

Pour les startups de moins de 50 ingénieurs, la bonne solution consiste à adopter de solides pratiques DevOps superposées aux outils SaaS. GitHub Actions, Vercel, Terraform Cloud et un répertoire de scripts partagés couvrent 90 % de vos besoins en infrastructure à une fraction du coût. Vous dépenserez entre 0 et 3 000 $/mois au lieu de 12 000 $ à 80 000 $/mois. Vous fournirez des fonctionnalités au lieu de créer des outils internes que seuls vos propres ingénieurs utilisent.

Lorsque votre équipe atteint 50 développeurs, lorsque l'intégration prend une semaine, lorsque vos ingénieurs DevOps ne parviennent pas à répondre aux demandes d'infrastructure ; c'est à ce moment-là que vous investissez dans une équipe de plateforme. Pas avant. La prédiction du Gartner se fera d’elle-même.

Questions fréquemment posées