Le Platform Engineering constitue une approche de plus en plus attractive dans le domaine de la livraison de logiciels, car elle présente des avantages tels qu’une mise en marché plus rapide, une satisfaction accrue chez les développeurs, et une augmentation de la synergie entre les équipes. Nous avons déjà écrit au sujet du Platform Engineering, en expliquant qu’il ne s’agit en fait pas d’une pratique inédite, et que le DevOps n’est pas devenu obsolète. Cependant, compte tenu du nombre d’entreprises qui ont eu du mal à générer de la valeur commerciale grâce au DevOps, ces dernières considèrent peut-être que la construction de plateformes numériques internes pour favoriser la livraison de logiciels est une stratégie qui permet de bénéficier de tous les bienfaits du DevOps.
Mais comment ne pas tomber dans le piège qui a empêché 80% des entreprises d’adopter le DevOps?
Notre conseil est le suivant : traitez votre plateforme comme vous traiteriez un produit interne, et les utilisateurs de votre plateforme comme vos clients. En l’occurrence, vos indicateurs de réussite, riches d’une touche de Platform Engineering, devraient être similaires à ceux employés pour vos clients.
Les objectifs fondamentaux du Platform Engineering
Lorsque vous établissez vos indicateurs de réussite, assurez-vous de ne pas perdre de vue les buts de votre stratégie de Platform Engineering. Nous vous présentons les principaux objectifs des entreprises pour leurs équipes sur les plateformes, selon le rapport de 2023 sur l’état du DevOps.
L’éducation et l’émancipation des équipes de développeurs et de conception sont des priorités capitales pour les équipes de plateforme, et elles sont complétées par la vitesse d’itération et la sécurité des processus. Cette approche centrée sur le personnel doit se retrouver dans vos indicateurs de réussite. La réinvention des outils ne représente que la moitié de la tâche : vous devez également vous assurer que vos équipes ont bien maîtrisé l’utilisation des nouveaux systèmes. Les processus de rationalisation et d’automatisation inspirés par les meilleures pratiques de DevX favorisent la productivité générale de l’entreprise ainsi que sa démarcation sur le marché.
Les ICP du Platform Engineering
Selon le report mentionné plus haut sur l’état du Devops, la majorité des entreprises qui ont adopté le Platform Engineering ont constaté des améliorations aux niveaux suivants : fiabilité du système (60%), productivité et efficacité (59%), flux de travaux (57%), auxquelles s’ajoutent une amélioration du temps de développement pour 42% de ces sociétés.
La productivité
Compter le nombre de lignes de code produites par les développeurs sur une période de temps donnée est un indicateur dépassé, qui n’intéresse aujourd’hui que des profils comme Elon Musk. La productivité des développeurs est un sujet sensible, et bien que le Platform Engineering garantit l’accélération de la mise au point de logiciels, celle-ci ne s’opère pas en augmentant les rendus des développeurs.
L’idée, c’est plutôt de leur offrir les meilleures conditions de travail possibles. Pensez à tous les obstacles et contretemps que vos équipes doivent affronter au quotidien et à leur dépendance vis-à-vis des experts pour travailler correctement. Les déploiements d’infrastructures complexes, la création de nouveaux environnements et de fonctionnalités de livraison, sont quelques exemples qui nécessitent une intervention DevOps, ce qui ralentit inévitablement les processus. Les ICP centrés sur la rationalisation et la simplification du processus de livraison de logiciels devraient être votre priorité.
Il s’agit d’une mesure qui calcule le temps entre la mise en place du récit utilisateur et sa livraison. Ce temps comprend les discussions sur le récit utilisateur, l’attente dûe aux retards, et la durée entre la sélection du récit et sa distribution finale.
Si votre délai de production est trop long, c’est le signe d’un obstacle au niveau des processus, qui conduit à l’éternisation des retards. Automatiser tout ce qui peut l’être limitera votre délai de production, car il s’agit d’une preuve de la proactivité de vos équipes pour atteindre leurs objectifs et s’adapter aux retours.
Deployment frequency tracks how often your end-users deploy code to production. It’s a good measure of the value your engineering teams can deliver to customers. However well-oiled your workflow may be, it can fail to deliver sufficient value if you’re not deploying frequently enough.
Cette mesure suit la fréquence des déploiements de code en production par l’utilisateur final. Elle permet d’estimer la valeur que peut apporter vos équipes d’ingénieurs à vos clients. Peu importe l’optimisation du flux de travaux, sa valeur peut s’avérer insuffisante si les déploiements sont trop peu fréquents.
- Satisfaction des développeurs
On pourrait se dire qu’associer le bonheur des développeurs à leur productivité est peu éthique, mais il s’avère heureusement que le niveau de satisfaction des développeurs est proportionnel à leur productivité. Le Platform Engineering vise justement une meilleure expérience pour les développeurs, ce qui explique l’importance de vérifier vos statistiques DevX.
La stabilité
La stabilité mesure la marge d’action des ingénieurs de production pour opérer des changements sans compromettre l’expérience du client final.
- Taux d’échec des modifications (CFR)
Ce taux mesure le pourcentage de déploiements en production qui ont échoué. Cet indicateur retardé permet d’observer clairement la qualité et la stabilité logicielles. Pour l’obtenir, il suffit de diviser le nombre de déploiements échoués par le nombre total de développements.
En suivant cet indicateur sur le long terme, vous pourrez estimer les efforts alloués à la solution des problèmes ainsi que ceux destinés au déploiement de code nouveau. Lorsqu’il affiche plus que 15 %, cela signifie sans doute que vos équipes passent trop de temps à régler des problèmes. Ce temps aurait pu être plus productif, certains processus doivent être optimisés.
- Temps moyen de réparation (MTTR)
Cet indicateur retardé estime le temps que met un service à reprendre son état normal après une interruption. Pour déterminer cet ICP, il faut calculer la durée nécessaire pour déployer un code de correction à la suite d’un signalement d’un incident.
Même les équipes de DevOps les plus aguerries font face à des difficultés et des imprévus de temps à autre. Les échecs sont inévitables : il s’agirait de savoir combien de temps il faut pour que les activités reprennent leur cours habituel après qu’ils se produisent.
L’efficacité
La productivité et l’efficacité sont souvent traitées de manière interchangeable, mais nous voulons nous pencher spécifiquement sur des indicateurs de rentabilité, qui comprennent le coût des ressources cloud, des infrastructures, des licences, et des équipes de Platform Engineering. Cette approche fait la part belle à l’utilisation efficace des ressources, donc les modules de FinOps et de GreenOps favoriseraient votre stratégie de ressources.
Cet indicateur rend possible des conversations productives sur l’équilibre entre les objectifs et la quantité fixe de ressources disponibles. Le Platform Engineering vous aide à distribuer ces ressources plus uniformément et à savoir où elles sont dépensées. Les cadres apprécieront particulièrement cet indicateur car il permet de vérifier si les travailleurs se concentrent bien sur les objectifs cruciaux de l’entreprise.
La connaissance des objets de vos dépenses vous permettra de mettre un terme aux dépassements des coûts dus au cloud et au gaspillage. Comme nous l’avons déjà expliqué, l’efficacité de l’utilisation des ressources est un des piliers du Platform Engineering, et c’est pourquoi nous encourageons les entreprises à privilégier la sobriété dans leur consommation du cloud.
Des ICP de coût transparents sont essentiels pour atteindre ce but. Offrir aux utilisateurs finaux ainsi qu’aux équipes sur la plateforme la possibilité de constater les répercussions financières de leur architecture avant le déploiement, en plus d’une vue d’ensemble holistique de tous les coûts relatifs au cloud, est l’élément charnière sur lequel repose la réussite de vos projets.
Les tableaux de bord des ICP du Platform Engineering
La plupart de ces ICP relèvent d’une responsabilité partagée entre les équipes : il faut le garder en tête lorsque vous regardez ces indicateurs. La transparence et l’observabilité participent à l’amélioration de la collaboration entre les équipes, donc des tableaux de bord des ICP exhaustifs et partagés sont à envisager. Voici, par exemple, à quoi ressemblent les ICP à Cycloid :
![1000 — Dashboard@3x](https://blog.cycloid.io/hs-fs/hubfs/1000%20%E2%80%94%20Dashboard@3x.png?width=590&height=445&name=1000%20%E2%80%94%20Dashboard@3x.png)
Ce qu’il faut retenir
En raison du fait qu’un tiers des équipes de Platform Engineering doivent encore faire face à la réticence des autres équipes dans leur organisation quant à l’adoption d’une plateforme, vous devriez surveiller le progrès de cette adoption, et le considérer comme un ICP plus général. Après tout, la plateforme est censée aider l’ensemble de l’entreprise et favoriser le rapprochement entre les équipes ; cela requiert une coopération de la part de tous.
Peu importe les indicateurs que vous choisissez, il faut rester réaliste au niveau des attentes de l’entreprise pendant les premières années de l’adoption d’une équipe de plateforme. Vos ICP évolueront au cours de votre parcours de Platform Engineering, mais au début, votre objectif devrait être de rendre l’ingestion et l’exploitation des données beaucoup plus aisées pour vos équipes.
Vous êtes intéressé par Cycloid Platform Engineering ? Recevez une démonstration personnalisée par notre équipe