Maintenance, dette technique et travaux transverses : ce que 100 équipes révèlent

L’essentiel

Pour la plupart des initiatives transverses, écrire le code est la partie facile. La difficulté commence après l’ouverture de la demande de tirage : obtenir que d’autres équipes l’examinent, qu’elles la priorisent par rapport à leur propre feuille de route, et savoir si la demande a finalement été fusionnée. C’est le constat qui ressort d’une enquête menée auprès de plus de 100 équipes – plateformes, infrastructures, expérience développeur et sécurité applicative – sur la façon dont elles gèrent les modifications de code touchant des dizaines, des centaines, voire près de 2000 dépôts.

Un ingénieur de plateforme d’une entreprise de technologie financière a résumé son expérience : « Même avec la demande de tirage prête, cela devient un problème de coordination humaine pour que le travail soit fait. » Ce témoignage reflète un constat généralisé : le temps passé n’est pas celui de l’écriture, mais celui de la relance dans les canaux de messagerie, des négociations sur la priorité, et de l’attente.

Là où le travail se bloque

Des équipes centralisées, une exécution décentralisée. Les groupes d’infrastructure et de plateforme sont souvent responsables de l’implémentation de directives qu’ils n’ont pas choisies : mise à jour de version d’un langage, correctif de sécurité, conformité réglementaire. Chaque initiative commence donc par une phase de négociation pour convaincre chaque équipe propriétaire de la prioriser, puis par de l’attente.

Des files d’attente saturées. La plupart des équipes interrogées indiquent que les responsables de services ont typiquement entre 30 et 50 demandes de tirage en attente avant qu’une nouvelle n’arrive. Un ingénieur d’une fintech décrit la réalité du côté récepteur : « Vous êtes 64e dans la file, revenez dans une semaine. » La simple existence de la demande ne modifie pas les comportements. Sans personne responsable de l’ensemble du déploiement, le travail s’enlise au moment de la fusion.

La dette technique perd face aux fonctionnalités chaque trimestre. Sauf urgence (vulnérabilité critique, fin de vie d’un composant, incident récent), les travaux de maintenance sont reportés. Un responsable de plateforme d’une place de marché l’a formulé sans détour : « Réalistement, très peu d’entreprises ont la capacité de gérer la dette technique en permanence. » Les initiatives doivent donc être menées comme des campagnes délibérées, et non comme un travail d’arrière-plan.

Les scripts de masse ont leurs limites. De nombreuses équipes ont essayé d’écrire des scripts pour ouvrir des demandes en lot. Cela fonctionne sur quelques dépôts, mais échoue sur le lot suivant à cause de variations imprévues. Même en cas de succès, ces scripts ne montrent rien de ce qui se passe après l’ouverture de la demande.

Ce qui a fonctionné

Les équipes qui ont bien géré ces initiatives partagent plusieurs habitudes, regroupées ici en trois phases : cadrage, réalisation, fusion.

Cadrer le changement

Au lieu de définir le changement une fois pour toutes, les équipes performantes l’ont calibré sur un petit lot de dépôts : un simple, un moyen et un difficile. Le but n’est pas de valider sur le plus simple, mais de découvrir ce qui se casse sur le plus difficile avant de passer à l’échelle. « La majeure partie du calibrage se fait lors de ces premiers essais », a rapporté un ingénieur d’une entreprise d’objets connectés.

La réutilisation de la documentation interne fait une différence notable. Les guides de migration déjà rédigés, les pages d’espace de travail notées ayant été relues par des pairs, et les documents de demande de commentaires sur une modification importante sont plus fiables que tout ce qui peut être écrit lors d’une réunion de planification. « Une page d’espace de travail est normalement très bonne car elle a été relue par des pairs. Plus d’effort a été investi que dans une simple invite », a expliqué un ingénieur d’une fintech, en référence à l’utilisation éventuelle d’un agent d’intelligence artificielle.

Les meilleurs candidats pour ces initiatives sont les changements mécaniques : mises à jour de dépendances, ajouts de configuration, standardisation de format de journaux, mises à jour de versions d’actions GitHub, montées de version de framework disposant de guides de migration publiés. Les candidats plus risqués sont ceux où la bonne réponse dépend de la compréhension de ce que fait réellement le service.

Réaliser le changement

Pour les travaux de complexité faible ou moyenne, la plupart des équipes convergent vers un modèle centralisé. Un petit groupe d’ingénieurs de plateforme, d’expérience développeur ou d’ingénieurs seniors écrit le changement, génère les différences, ouvre les demandes de tirage en lot, et en assure le suivi. Cela permet de capitaliser sur l’expertise, de maintenir la cohérence des modifications, et d’éviter que chaque équipe doive réapprendre la procédure.

Obtenir la fusion effective

Le seul indicateur de complétude qui compte est la fusion, pas l’ouverture de la demande. Les équipes les plus efficaces traitent la fusion comme la seule métrique d’achèvement, et non le nombre de demandes envoyées. Cette différence de mesure change le comportement : elle oblige à suivre chaque demande jusqu’à son terme, à relancer les équipes qui traînent, et à remonter au leadership les blocages par équipe.

« Même avec la demande de tirage prête, cela devient un problème de coordination humaine pour que le travail soit fait. »

Les anti-patrons à éviter

L’enquête identifie plusieurs pratiques qui nuisent à l’efficacité :

• Créer des tickets et attendre. Déposer un ticket dans le système de suivi ne garantit pas que le travail sera fait, ni même priorisé.
• Laisser les robots de mise à jour fonctionner sans supervision. Des outils automatisés comme Renovate peuvent ouvrir des demandes sans discernement, submergeant les équipes.
• Activer la fusion automatique sans revue. Cela court-circuite la relecture de code et peut introduire des régressions.
• Utiliser des outils de codage par intelligence artificielle pour des changements multi-dépôts. Ces outils sont conçus pour la boucle de développement individuelle et peinent à gérer la coordination et les variations entre dépôts.
• Compter les demandes de tirage ouvertes comme une progression. Ce chiffre flatteur n’indique pas que le changement a été accepté, testé et fusionné. Une demande ouverte peut rester sans suite indéfiniment.

Où la technologie s’insère

Le constat général est que la plupart des outils d’intelligence artificielle se concentrent sur la « boucle intérieure » du développement – l’écriture du code – et ne traitent pas la « boucle extérieure » : la coordination, la priorisation, le suivi jusqu’à la fusion. Les équipes qui réussissent utilisent des approches combinant automatisation du changement et suivi humain de l’avancement, avec une visibilité pour les responsables sur l’état d’avancement par équipe.

Un guide pratique a été publié pour accompagner ces démarches, détaillant les tactiques de cadrage, d’exécution et de suivi des initiatives transverses.