Créer un outil interne à l’aide d’agents de programmation est devenu beaucoup plus rapide, mais les données du rapport Future of Platform Engineering 2026 indiquent que la facilité de construction ne signifie pas nécessairement que l’on dispose d’une vision claire. Parmi les 379 spécialistes de l’ingénierie des plateformes, les équipes qui construisent elles-mêmes la plupart de leurs fonctionnalités étaient environ 3,5 fois plus susceptibles de considérer l’absence d’une stratégie claire comme un obstacle.
Ce résultat ne prouve pas que construire à partir de zéro soit une mauvaise décision, mais il révèle une corrélation entre la manière de fournir les capacités de la plateforme et le niveau de clarté de l’orientation suivie par les équipes.
Les outils prêts à l’emploi sont l’option la plus courante
51,3 % des participants ont déclaré que l’utilisation d’un outil de base prêt à l’emploi constituait leur principale approche pour prendre en charge les fonctionnalités de la plateforme, contre 31,2 % qui s’appuient sur des modèles existants et 17,5 % qui construisent à partir de zéro. Le recours aux outils était plus élevé parmi les équipes classées comme très performantes, à 58,8 %, contre 47,8 % pour les modèles et 33,3 % pour la construction à partir de zéro.
Les exceptions apparaissent dans les environnements directement liés à un parcours technique donné, comme les environnements de développement locaux, les projets créés en un clic et les environnements éphémères. Dans ces cas, les modèles peuvent offrir une compatibilité avec les parcours approuvés que les outils généraux fournissent difficilement.
Les environnements éphémères sont un indicateur de maturité de la plateforme
Les équipes qui fournissent des environnements éphémères étaient davantage susceptibles de signaler un effet positif de l’IA sur la vitesse et la stabilité de la livraison logicielle, ainsi que sur la couverture du code et le contrôle des coûts. Parmi les équipes qui qualifiaient cet effet de très positif, plus des trois quarts utilisaient des environnements éphémères.
Cette relation ne signifie toutefois pas nécessairement que l’environnement éphémère, à lui seul, a provoqué l’amélioration. Les équipes qui en fournissent travaillent souvent au sein de plateformes plus vastes intégrant plusieurs capacités automatisées, ce qui peut faire de l’étendue et de la maturité de la plateforme des facteurs plus importants pour absorber le volume de changements produits par l’IA sans sacrifier la stabilité.
Pourquoi cette information est-elle importante ?
Le principal changement pratique est que l’IA réduit le coût d’écriture du code, mais n’élimine pas le coût de sa possession. Un outil construit rapidement nécessite une maintenance, des mises à niveau et une gouvernance, et peut accroître la charge opérationnelle à mesure que le volume de changements sur le parcours de développement augmente.
Les données appuient cette distinction : 57,9 % des équipes qui construisent majoritairement à partir de zéro ont déclaré que l’absence d’une stratégie claire constituait un obstacle, contre 15,6 % des équipes qui s’appuient sur des modèles et 16,7 % de celles qui utilisent des outils de base. Les équipes qui construisent à partir de zéro utilisaient également davantage l’IA pour moderniser les anciens systèmes et migrer les langages, ce qui laisse entendre qu’une partie de cet usage sert à maintenir des complexités créées par les équipes elles-mêmes.
La question ne se résume pas à construire ou acheter
L’analyse des coûts et des bénéfices était la raison la plus courante des décisions de construire ou d’acheter, à 29,6 %, suivie par la préférence pour l’open source à 28,6 %, puis par l’évaluation de l’adéquation et des exigences à 22,4 %, la préférence pour les outils commerciaux à 22,4 %, et la construction visant à obtenir une différenciation fondamentale à 16,3 %.
Le texte propose deux interprétations possibles, sans que les données permettent de trancher entre elles : la stratégie peut précéder la décision de construire ou d’acheter, ou la construction peut elle-même devenir une solution temporaire en remplacement d’une stratégie qui n’est pas encore définie. Mais la conclusion éditoriale la plus claire est que le problème ne réside pas dans la construction à partir de zéro, mais dans son adoption par défaut sans raison précise. Les capacités uniques doivent être construites autour du contexte de l’organisation, tandis que les outils qui résolvent efficacement des problèmes standardisés doivent être achetés ou adoptés, en tenant compte du coût de la maintenance et de la dépendance à long terme.