Commencer par l’avant limite la flexibilité
L’ingénierie des plates-formes n’est pas une question de tableaux de bord ou d’interfaces utilisateur soignées. Ce n’est pas là que se trouve l’effet de levier. Si votre équipe construit d’abord la partie frontale, vous donnez la priorité à la perception plutôt qu’à la performance. C’est l’une des erreurs les plus courantes et les plus faciles à éviter dans les projets de plateformes modernes.
Les interfaces frontales sont utiles, oui. Des outils comme Backstage sont largement adoptés et apportent une valeur ajoutée. Mais ils ne sont qu’une coquille. Le véritable moteur, ce qui alimente vraiment une plateforme de développement internese trouve sous la surface. Il se trouve dans les API, les couches d’automatisation, l’orchestration de l’infrastructure. C’est là que les développeurs obtiennent vitesse et fiabilité. Si cette base est fragile, même la plus belle interface ne sauvera pas l’adoption.
Viktor Farcic, défenseur des développeurs chez Upbound, a souligné un point essentiel : le fait de placer la logique de votre plateforme à l’intérieur du portail vous enferme dans une seule façon d’interagir avec elle. C’est une limitation. Les développeurs veulent de la flexibilité. Certains utilisent des interfaces graphiques. D’autres utilisent des CLI ou des API. Ignorer cette diversité pousse les développeurs à contourner entièrement votre outil, ce qui signifie que vous les perdez avant même d’avoir commencé.
Luca Galante, qui contribue à la communauté Platform Engineering, l’a dit clairement : commencez par un back-end solide. Les fondations doivent être solides. Vous pouvez toujours ajouter une interface utilisateur par la suite. C’est une solution plus intelligente. Elle permet l’évolutivité. Elle donne le choix aux développeurs. Et elle permet à votre plateforme de rester adaptable à long terme, ce qui est exactement ce que vous souhaitez.
L’adoption d’une plate-forme passe par l’adoption d’une mentalité axée sur le produit
Une plateforme sans esprit de produit n’est qu’un code sans objet. C’est la différence entre construire un outil et construire quelque chose que les gens veulent utiliser. Les plateformes internes ne font pas exception. S’attendre à ce que les développeurs adoptent quelque chose sans raconter d’histoires, sans plaidoyer ou sans boucles de rétroaction, c’est prendre ses désirs pour des réalités, et cela ne fonctionne pas.
Erica Hughberg, responsable chez Tetrate, l’a clairement expliqué lors de la KubeCon 2024. Elle a déclaré que s’appuyer sur les ingénieurs pour conduire l’adoption de la plateforme seule est une « recette pour le désastre ». Ce n’est pas une exagération. Vous pouvez concevoir quelque chose d’impressionnant, d’un point de vue fonctionnel. Mais même les meilleurs produits ne se vendent pas d’eux-mêmes. Ils sont façonnés, promus et constamment affinés. Pensez comme une équipe produit, car vous en êtes une.
Mettez rapidement une plate-forme minimale viable entre les mains des développeurs. Ensuite, écoutez. Répétez. Mesurez. Il ne s’agit pas de perfection, mais de pertinence. Luca Galante, de Platform Engineering, recommande de suivre l’impact au fil du temps. C’est ce qui permet à la plateforme de respirer. Si vous ne vous améliorez pas constamment, vous êtes à la traîne.
Cet état d’esprit à l’égard des produits n’est pas superflu. C’est le retour sur investissement. Lorsque vous construisez avec un objectif et que vous le commercialisez en interne, l’adoption suit, de manière organique et à grande échelle.
Donnez une identité à votre plateforme. Montrez votre valeur avant de demander un engagement. Faites ce changement et vous verrez la différence. Les équipes ne se contentent pas d’utiliser la plateforme, elles s’y fient.
La propriété partagée et l’adhésion des promoteurs sont essentielles à l’engagement.
La mise en œuvre descendante tue la confiance. Si vous imposez une plateforme aux développeurs sans leur demander leur avis, ils la rejetteront ou construiront leurs propres solutions de contournement. C’est du temps perdu. De l’innovation perdue. C’est la voie de la fragmentation, et non de l’adoption.
La propriété partagée résout ce problème. Elle transforme l’ingénierie des plateformes en quelque chose de participatif. Tom Barkan-Benkler, directeur de la gestion des produits chez Spotify, l’a bien expliqué : donnez aux équipes la liberté de contribuer. Laissez-les écrire des plugins. Laissez-les façonner la plateforme en fonction de leurs flux de travail.
Spotify ne se contente pas de parler de ce modèle, il l’applique. Ils ont construit « Soundcheck » comme un plugin à l’intérieur de Backstage, leur portail de développement interne, pour soutenir la validation de la livraison continue. Plus important encore, leur modèle ouvert signifie que chaque ingénieur peut étendre la plateforme. C’est un multiplicateur de force. Les développeurs n’ont pas besoin de demander la permission pour améliorer leurs outils, ils les améliorent tout simplement.
Le résultat ? Pia Nilsson, directrice principale de l’ingénierie chez Spotify, a confirmé que 100 % des employés utilisent leur instance interne de Backstage. Ce n’est pas le résultat d’un mandat. Il s’agit d’une copropriété qui génère une valeur intrinsèque.
Jay Jenkins, directeur technique de l’informatique Cloud chez Akamai, l’a très bien exprimé : la gouvernance doit donner des moyens d’action et non des restrictions. Vous avez besoin d’une structure, mais elle doit inviter à la contribution et non la limiter. Les plateformes réussissent lorsque les développeurs ont le sentiment d’avoir participé à leur construction. C’est alors que votre plateforme devient un écosystème.
Une étude approfondie des utilisateurs est essentielle pour créer des plateformes pertinentes.
Les équipes d’ingénieurs ne sont pas uniformes. Développeurs, ingénieurs d’assurance qualité, équipes de fiabilité des sites, ils fonctionnent différemment, ont besoin d’outils différents et attendent des capacités spécifiques. Pourtant, trop d’initiatives en matière de plateformes sont lancées sur la base d’hypothèses. C’est un risque que vous ne pouvez pas vous permettre de prendre.
Andreas Grabner, un défenseur de DevOps chez Dynatrace, l’a dit clairement : si vous construisez une plateforme sans bien connaître vos utilisateurs, vous construisez quelque chose qui ne fera pas bouger l’aiguille de l’efficacité de l’ingénierie. C’est peut-être bien sur le papier, mais cela ne favorisera pas l’adoption ou ne résoudra pas les goulets d’étranglement réels.
Commencez par écouter. Recueillez les commentaires avant d’écrire la première ligne de code. Vous obtiendrez ainsi des signaux clairs. Quels sont les besoins de vos équipes ? Quels sont les flux de travail qui ne fonctionnent pas ? Où est la perte de temps ?
Zohar Einy, PDG de Port, a souligné cet aspect humain. Lorsque les équipes voient leurs commentaires reflétés dans les résultats de la plateforme, l’adoption augmente. Les gens soutiennent ce qu’ils ont contribué à définir. Il ne s’agit pas seulement d’un sentiment, mais d’une stratégie. Cela garantit que la plateforme s’aligne sur le travail réel et quotidien.
Pour les dirigeants, il s’agit d’une démarche simple. La recherche précoce permet de réduire le gaspillage, d’accélérer l’itération et d’apporter des fonctionnalités là où elles sont le plus nécessaires. C’est un investissement dans la clarté et l’efficacité à long terme. Ne faites pas l’impasse. Vous en tirerez des dividendes.
Se concentrer sur les mauvais indicateurs peut fausser les investissements dans les plates-formes
Regarder les mauvais chiffres conduit à de faux signaux. Il est facile de tomber dans le piège des statistiques d’intégration ou de l’utilisation d’outils comme signes de réussite. Mais il s’agit là d’indicateurs de surface. Ils ne montrent pas l’impact de votre plateforme sur l’entreprise.
Andreas Grabner de Dynatrace souligne que de nombreuses équipes s’appuient trop lourdement sur les mesures DORA, le délai d’exécution, la fréquence de déploiement, le taux d’échec des changements. Utiles, certes, mais ce sont des indicateurs de suivi du point de vue de l’ingénierie de plateforme. Ils ne vous permettent pas de savoir si vos investissements augmentent la productivité ou réduisent les frictions en temps réel.
Si vous voulez savoir si votre plateforme de développement interne est importante, concentrez-vous sur la réduction des délais de mise sur le marché, la diminution des coûts d’infrastructure et l’accélération de l’innovation de vos équipes d’ingénieurs. Kaspar von Grünberg, PDG d’Humanitec, est très clair à ce sujet : Le retour sur investissement doit être défini avant la construction d’un seul composant. Si vous ne savez pas à quoi ressemble ce qui est « bon », vous ne pouvez pas mesurer les progrès et vous ne pouvez pas justifier les dépenses.
Pour les dirigeants de la suite, la conclusion est claire. Exigez des mesures qui reflètent l’impact sur l’activité de l’entreprise. Traitez les statistiques d’utilisation comme des signaux et non comme des résultats. L’adoption ne signifie rien si elle ne se traduit pas par une valeur stratégique. Les indicateurs doivent relier les performances de votre plateforme à des objectifs que vous pouvez présenter au conseil d’administration.
Copier les stratégies des grandes entreprises peut s’avérer contre-productif
Ce n’est pas parce que cela a fonctionné chez Spotify ou Expedia que cela fonctionnera pour vous. Les grandes entreprises disposent d’avantages uniques – échelle, budget, bande passante technique – qui ne s’appliquent pas à toutes les entreprises. L’adoption de leurs modèles de plateformes internes sans ajustement se traduit souvent par des constructions excessives et des attentes déçues.
Himanshu Mishra, chef de produit chez Harness et ancien membre de l’équipe Backstage chez Spotify, nous met en garde contre cette pratique. Selon lui, le retour sur effort est plus important que l’adéquation des capacités. Les petites équipes peuvent déployer les mêmes efforts qu’une grande entreprise, mais elles n’obtiendront souvent pas le même retour sur investissement. Ce décalage fait perdre du temps et des ressources.
Camille Fournier, conseillère chevronnée et auteur du livre Platform Engineering d’O’Reilly, n’est pas non plus impressionnée par les architectures de référence. Elle souligne qu’elles n’abordent pas les aspects difficiles, les abstractions, les limites de l’évolutivité, le maintien des normes d’observabilité à travers des piles d’applications variées. Les modèles sont utiles, mais ils ne résolvent pas la complexité fondamentale.
Pour les dirigeants, le conseil est simple : soyez stratégique. Empruntez des idées, mais alignez chaque choix de conception sur les besoins réels de votre entreprise. Copier aveuglément ne comblera pas les lacunes en matière de capacités. C’est en construisant à partir de ce dont vos équipes ont besoin maintenant que vous y parviendrez.
Une ingénierie trop poussée dans les premières phases crée une complexité inutile
Essayer de répondre à tous les cas d’utilisation possibles dès le départ conduit à une complexité qui ralentit les équipes. De nombreux efforts d’ingénierie de plateforme échouent rapidement parce qu’ils se concentrent sur des futurs hypothétiques au lieu de résoudre les problèmes réels d’aujourd’hui.
Himanshu Mishra de Harness conseille une approche pragmatique : commencez par les flux de travail de base des développeurs, en particulier CI/CD. Réduisez les frictions là où elles sont les plus importantes. Lorsque ces domaines sont rationalisés, vous créez la confiance et prouvez la valeur dès le début. Plus tard, des capacités supplémentaires pourront être ajoutées sur la base d’une demande claire, et non d’hypothèses exagérées.
Camille Fournier, directrice technique expérimentée et auteur d’ouvrages sur l’ingénierie des plates-formes, soutient ce point de vue. Elle recommande de se concentrer d’abord sur les domaines négligés qui causent une douleur commune à toutes les équipes. L’ajout de fonctionnalités complexes trop tôt crée un gonflement et un encombrement de l’expérience.
Jay Jenkins, directeur technique de l’informatique Cloud chez Akamai, ne mâche pas ses mots : si votre plate-forme ajoute plus de travail qu’elle n’en supprime, vous faites fausse route. L’efficacité doit augmenter. La complexité doit être gérée. Une plate-forme qui consomme plus de temps de développement qu’elle n’en économise est fondamentalement défectueuse.
Les dirigeants devraient donner la priorité aux résultats plutôt qu’à la portée. Les premières victoires créent une dynamique. La stabilité vient de l’ordre et non du volume. Si la plateforme ne vous facilite pas la vie dès les premières versions, c’est que vos fondations ont besoin d’être réévaluées, et non d’être étendues.
Il est inefficace de donner une nouvelle image aux équipes opérationnelles sans procéder à des changements fondamentaux.
Renommer votre équipe d’infrastructure en « ingénierie de plateforme » ne résout rien. Cela ne change pas l’état d’esprit, les flux de travail ou les résultats. Il s’agit d’une mesure superficielle qui crée une apparence sans progrès.
Paula Kennedy, directrice de l’exploitation et cofondatrice de Syntasso, en a fait l’expérience. Elle a observé des organisations renommer simplement les équipes d’exploitation ou d’infrastructure dans l’espoir de s’aligner sur les tendances actuelles. Mais à moins que ces équipes n’adoptent de nouvelles pratiques, l’engagement des utilisateurs, la réflexion sur les produits, le développement itératif, rien ne s’améliore réellement.
Camille Fournier est clair sur ce qui est nécessaire : l’ingénierie de plateforme exige un changement de culture. Il faut considérer l’infrastructure non pas comme un moyen de limiter les coûts, mais comme un produit qui aide les équipes logicielles à avancer plus vite, de manière plus sûre et plus cohérente. Il s’agit là d’un modèle opérationnel différent, qui nécessite des priorités différentes de la part des dirigeants.
Pour les dirigeants de haut niveau, il s’agit d’une question d’engagement. Vous ne pouvez pas attribuer de nouveaux titres et attendre des résultats. Vous devez guider la transformation de manière délibérée : nouvelle vision, objectifs significatifs, impact mesurable. Si vous ne le faites pas, vous n’obtiendrez pas de résultats. Vous obtiendrez une nouvelle plaque et les mêmes goulets d’étranglement.
L’ingénierie des plates-formes est une initiative continue et évolutive
L’ingénierie des plates-formes ne s’arrête pas là. Elle évolue. L’idée que vous pouvez « achever » une plateforme de développement interne est trompeuse et conduit souvent à la stagnation. Ce qui fonctionne aujourd’hui pourrait ne plus correspondre aux besoins de développement dans six mois. Les plateformes les plus efficaces s’adaptent en permanence.
Zohar Einy, PDG de Port, et Himanshu Mishra de Harness soulignent tous deux l’importance d’adopter l’état d’esprit d’un gestionnaire de produits. Cela signifie que vous devez considérer votre plateforme non pas comme une infrastructure à entretenir, mais comme un produit qui doit produire des résultats. Elle doit évoluer en fonction de l’utilisation, du retour d’information et de l’impact mesurable.
Pour réussir, les plateformes internes doivent répondre aux besoins des développeurs là où ils se trouvent. Cela signifie réduire les tâches répétitives, normaliser les flux de travail et offrir une automatisation qui permet de gagner du temps. Si elles sont bien conçues, les plateformes deviennent des accélérateurs silencieux. Mais rien de tout cela ne se fait automatiquement. Il faut de l’itération. Il faut un retour d’information. Il faut investir.
Tom Barkan-Benkler, de Spotify, a souligné ce qui est en train de devenir un principe reconnu : la copropriété est importante. Les développeurs doivent avoir leur mot à dire dans l’élaboration de la plateforme. L’adhésion de la direction permet d’assurer le financement. L’adhésion de l’équipe permet d’en préserver l’utilité.
Mais les résultats prennent du temps. Selon le rapport DORA 2024, le fait de disposer d’une équipe dédiée à l’ingénierie des plateformes n’a augmenté la productivité des développeurs que de 6 %. Dans le même temps, elle a réduit le débit de 8 % et la stabilité des changements de 14 %. Ces données envoient un message clair : les avantages de l’ingénierie de plateforme ne se matérialisent pas sans un effort stratégique et continu. Il ne suffit pas de construire pour gagner. Vous construisez, vous adaptez et vous améliorez, ou bien vous êtes dans l’impasse.
Pour les dirigeants, cela nécessite une réflexion à long terme. Allouez des ressources au-delà du lancement. Fixez des objectifs mesurés en termes de résultats, et non de produits. Et insistez pour que les systèmes reflètent l’utilisation réelle et permettent une innovation plus rapide. C’est ainsi que l’ingénierie des plateformes devient un avantage durable, et non un projet ponctuel.
Réflexions finales
Si vous voulez que l’ingénierie de plateforme fonctionne, vous ne pouvez pas la traiter comme un projet secondaire ou un échange de titres. Il s’agit d’une capacité stratégique. Elle a un impact sur la vitesse, les coûts, l’innovation et la fidélisation des développeurs. Bien menée, elle devient une infrastructure qui amplifie activement vos efforts d’ingénierie.
Mais elle ne fonctionne que si elle est construite avec intention. Cela signifie qu’il faut penser comme une équipe produit. Cela signifie qu’il faut connaître vos utilisateurs sur le bout des doigts, mesurer l’impact réel et procéder à des itérations sur la base d’un retour d’information exploitable. L’adoption n’est pas le fruit d’un mandat venu d’en haut. C’est la copropriété qui le fera.
Évitez la suringénierie, ignorez les mesures de vanité et arrêtez de copier ce qui ne convient pas. Construisez ce dont vos équipes ont réellement besoin. Puis optimisez au fil du temps.
Pour les dirigeants, l’ingénierie des plates-formes est un travail de longue haleine. Mais le retour sur investissement est réel lorsqu’il s’accompagne d’une discipline, d’une vision et des bons intrants. Faites en sorte que l’investissement compte. Dirigez-le avec la même attention que vous appliqueriez à n’importe quel produit contribuant à votre résultat net.
