La plupart des discussions sur l’ingénierie de plateforme et les plateformes internes pour développeurs (IDP) commencent avec un objectif bien connu : réduire la charge cognitive des développeurs de logiciels.
C’est un objectif légitime, et c’est habituellement là que commencent les conversations sur les IDP. Toutefois, lorsque nous avons commencé à travailler sur des plateformes de niveau entreprise, un autre problème est apparu très rapidement.
La plus grande friction ne touchait pas seulement les développeurs d’applications, mais aussi les équipes qui devaient concevoir, maintenir et automatiser l’infrastructure et les plateformes sur lesquelles tous les autres comptaient.
Notre mandat initial était de créer une solution d’ingénierie de plateforme qui intègre les meilleures pratiques, un IDP personnalisable et extensible, et les compétences adéquates pour tout gérer à un seul endroit. Nous avons réussi à créer tout cela en mettant l’accent principalement sur la productivité des développeurs. En approfondissant les défis opérationnels quotidiens, nous avons volontairement adopté un nouveau point de vue. Nous avons commencé à traiter les ingénieurs en automatisation, les SRE (ingénieurs fiabilité du site) et les opérateurs d’infrastructures comme des utilisateurs à part entière de la plateforme. Ce changement de perspective nous a permis de concevoir quelque chose de plus utile : non seulement un catalogue, mais un véritable environnement de travail où les équipes de plateforme peuvent créer, tester, gouverner et opérer l’automatisation de manière plus cohérente. En fait, nous avons réorienté l’ensemble de la solution d’ingénierie de plateforme pour qu’elle s’adresse aux ingénieurs de plateforme, aux ingénieurs d’opérations d’infrastructure, aux SRE, aux ingénieurs fiabilité réseau, etc. Désormais, les mêmes concepts d’ingénierie de plateforme destinés aux développeurs logiciels sont utilisés pour l’automatisation et pour les développeurs liés à la GenAI, mais spécifiquement pour l’automatisation liée à l’approvisionnement, la mise à niveau et l’exploitation des plateformes et des infrastructures.
Le goulot d’étranglement caché des opérations applicatives
Dans de nombreux grands environnements, les opérations applicatives ralentissent parce que l’automatisation des plateformes et des opérations applicatives est dispersée. Nous avons vu des scripts hébergés dans différents référentiels, de l’infrastructure-as-code exécutée à partir de machines individuelles, et les connaissances sur les versions d’applications et de plateformes centralisées auprès de quelques ingénieurs expérimentés. Rien de tout cela n’était mal intentionné. Il ne s’agissait que de la conséquence des équipes qui résolvent des problèmes urgents au fil du temps sans modèle opérationnel commun. L’impact devenait visible dès qu’une équipe d’application avait besoin d’un nouvel environnement, d’une mise à jour du pipeline de publication ou d’un changement de configuration. La demande se traduisait généralement par un billet, puis l’attente débutait.
Ce qui nous est apparu clairement, c’est que le retard ne venait que rarement d’un manque de capacité. Les équipes d’opérations applicatives savaient ce qu’elles faisaient. Le véritable problème était que chaque changement demandait trop d’efforts manuels, trop de changements de contexte et trop de vérifications minutieuses. Si nous voulions améliorer les cycles de publication des applications, il fallait d’abord améliorer le flux de travail quotidien des ingénieurs qui conçoivent et supportent ces pipelines de publication. La solution IDP de HCL est devenue l’endroit où ce flux de travail a été centralisé.
L’introduction de l’ingénierie de plateforme et d’IDP pour les plateformes s’est révélée salvatrice pour les opérations applicatives. Désormais, les cycles de publication critiques sont gérés par des automatisations à un clic. Et tous les scripts d’automatisation sont conservés dans GitHub avec les modèles de base accessibles via l’IDP, ce qui a accru la réutilisabilité et réduit considérablement les délais de traitement.
Personnalisation de Backstage pour AppOps et la gestion de plateforme
Notre solution IDP est basée sur Backstage, qui est robuste pour cataloguer les services et composants logiciels, mais il fallait qu’elle représente les actifs réellement utilisés chaque jour par nos équipes AppOps et plateforme.
Nous avons étendu le catalogue pour inclure des modules Terraform, des modèles de pipeline CI/CD, des scripts opérationnels, des chartes Helm, des modèles de configuration et des définitions de politiques-as-code. Cela a permis aux ingénieurs de trouver à un seul endroit les actifs d’automatisation approuvés, plutôt que de chercher dans de multiples référentiels ou de demander la dernière version à leurs collègues.
Ce petit ajustement a transformé l’utilité de la plateforme. Les ingénieurs en automatisation pouvaient voir ce qui existait déjà, comprendre les dépendances, réviser l’historique d’exécution et réutiliser des modèles avec plus de confiance. Au fil du temps, cela a aussi réduit le nombre de solutions uniques créées pour des besoins similaires d’environnements et de publication.
Code généré par l’IA intégré dans HCL IDP
La solution HCL IDP, dans le cadre du framework CARE, a été considérablement modifiée et plusieurs fonctionnalités additionnelles y ont été ajoutées au cours des dernières années. Toutes ces fonctions additionnelles sont issues de la rétroaction client et de l’évolution technologique avancée en cours.
Un des ajouts les plus pratiques a été un assistant alimenté par l’IA à l’intérieur de l’expérience IDP. Nous ne l’avons pas positionné comme un substitut au jugement d’ingénierie, mais plutôt comme un moyen d’éliminer certaines tâches répétitives dans l’écriture de code d’automatisation de plateforme et de configuration. Les SREs d’AppOps continuaient de réviser, ajuster et valider le résultat, mais le point de départ était beaucoup plus rapide.
L’assistant a été ajusté selon nos modèles d’architecture interne, nos exigences en matière de sécurité et nos outils privilégiés. Par exemple, lorsqu’un ingénieur avait besoin d’un manifeste Kubernetes, d’un playbook Ansible ou d’une charte Helm pour un usage spécifique, l’assistant pouvait générer une ébauche conforme à nos standards. Le vrai avantage n’était pas que l’IA écrivait du code. L’avantage, c’est que les ingénieurs passaient moins de temps sur le code standard et plus de temps à réfléchir aux risques, aux dépendances et à l’impact opérationnel.
Plans types pour un déploiement de plateforme accéléré
Nous avons aussi appris que générer le code d’automatisation ne représentait que la moitié du problème. La question la plus importante est l’endroit où le tester en toute sécurité. Avant, les ingénieurs avaient souvent un accès limité à des environnements tests réalistes et valider une modification d’infrastructure pouvait exiger la coordination de plusieurs équipes. Cela engendrait de l’hésitation, surtout pour les changements touchant le réseau, les migrations de bases de données, les politiques de cluster ou les services partagés de plateforme.
Pour remédier à cela, nous avons introduit des plans types de déploiement de plateforme à l’intérieur de l’IDP. Il ne s’agissait pas de modèles d’applications génériques. Ils étaient conçus pour la validation au niveau plateforme, et notre solution phare ePACE était utilisée en tant que facilitateur. Un ingénieur pouvait créer un environnement Kubernetes éphémère avec la pile standard de la plateforme, appliquer un nouveau script ou une nouvelle configuration, observer le comportement puis détruire l’environnement une fois les tests terminés. Tout cela était géré dans ePACE, exécuté en arrière-plan par l’IDP de façon transparente.
Cela offrait aux équipes un moyen plus sûr d’expérimenter. Cela ne supprimait pas la nécessité de réviser ou de contrôler les changements, mais diminuait la crainte de tester des changements d’infrastructure. Les ingénieurs pouvaient valider le comportement dans un environnement beaucoup plus proche de la production, sans mettre en péril des charges actives. Le nettoyage automatique permettait aussi d’éviter le problème classique des environnements de test laissés actifs indéfiniment.
Observabilité en temps réel pour plus de clarté opérationnelle
Un autre problème que nous souhaitions résoudre était la visibilité opérationnelle. En pratique, les ingénieurs devaient souvent passer de l’IDP, aux outils de journalisation, aux tableaux de bord de surveillance et aux systèmes de pipeline pour comprendre si une modification s’était déroulée comme prévu. Ce changement de contexte rendait le dépannage plus lent et compliquait la connexion entre une action de déploiement et son impact opérationnel.
Nous avons intégré les principales vues d’observabilité dans HCL IDP, afin que les équipes puissent voir l’utilisation des ressources, la latence, les taux d’erreur et l’état des environnements au même endroit où elles initient ou révisent les changements de plateforme. Cela a rendu les révisions plus concrètes. Si un nouveau script d’automatisation augmentait la consommation de ressources ou générait des erreurs, l’équipe voyait rapidement le signal et pouvait réagir avec un meilleur contexte.
Favoriser la durabilité grâce aux tableaux de bord GreenOps
À mesure que la plateforme a mûri, nous avons également élargi notre regard au-delà de la rapidité et de la fiabilité. Les coûts et la durabilité sont devenus des sujets essentiels dans la discussion. Nous avons intégré Kepler, l’exportateur de niveau d’efficacité énergétique basé sur Kubernetes, pour offrir une visibilité sur les habitudes de consommation énergétique au niveau des charges de travail. Cela était utile, car cela reliait l’efficacité de l’infrastructure aux choix de conception applicative.
Pour les développeurs, l’efficacité devenait ainsi plus visible. Plutôt que d’avoir accès seulement aux données de processeur et de mémoire, ils pouvaient aussi comprendre l’impact énergétique de leurs services. Nous avons constaté que cela permettait de passer d’objectifs abstraits de durabilité à des choix d’ingénierie spécifiques, tels que le dimensionnement adéquat des charges, la réduction du traitement inutile en arrière-plan et l’amélioration de processus de code inefficaces.
Transformation du cycle de vie applicatif et plateforme
Avec du recul, la leçon principale a été qu’un IDP devient bien plus précieux quand il reflète le vrai flux de travail des équipes d’exploitation de la plateforme. En mettant l’accent sur les ingénieurs en automatisation et les SREs, nous avons amélioré la base sur laquelle comptent les équipes applicatives. Les scripts pouvaient être générés plus rapidement, testés de façon plus sécuritaire, réutilisés de manière plus uniforme et observés avec plus de contexte.
Le résultat n’a pas été une transformation soudaine engendrée par un portail, mais plutôt une amélioration progressive de la gestion des environnements, des opérations de publication et de l’automatisation de l’infrastructure. Les équipes applicatives en ont bénéficié parce que les équipes plateforme avaient de meilleurs outils. Les équipes plateforme ont bénéficié parce que leur travail est devenu plus normalisé et plus facile à valider. Pour nous, c’était la vraie valeur de repenser l’IDP : le rendre utile pour ceux qui assurent discrètement la continuité de livraison.
