Gérer la dette technique avec DX et IA

Chaque entreprise, grande ou petite, s’inquiète de la dette technique. Selon Gartner, environ 40 % des systèmes d’infrastructure ont ce problème. Dans une enquête menée auprès des DSI par McKinsey, près d’un tiers estimaient que plus de 20 % de leur budget de nouveaux produits était consacré à la résolution de problèmes liés à la dette technique. Mais contrairement à ce que beaucoup pensent, ce n’est pas seulement un problème de codage ; c’est également un problème d’expérience développeur (DX). Car lorsque les développeurs doivent travailler avec une architecture inadéquate, des outils obsolètes et des flux de travail de développement médiocres, la productivité, les performances et le moral souffrent.

En donnant la priorité à la dette technique en tenant compte du développeur, en se concentrant sur la façon dont ils abordent le travail, les outils qu’ils utilisent et les avancées de carrière qu’ils peuvent obtenir, les équipes se concentrent et livrent plus rapidement. C’est pourquoi la façon dont les entreprises gèrent la dette technique change, sous l’impulsion de la DX et d’une attention accrue à l’outillage alimenté par l’IA.

Plaidoyer pour la DX

La façon dont les développeurs sont souvent intégrés laisse beaucoup à désirer. Il peut falloir deux semaines à quelqu’un pour commencer à contribuer à un projet. Une fois qu’ils ont enfin pu ajouter de petites fonctionnalités ou des correctifs, il n’est pas rare de voir le service d’intégration continue (CI) échouer en raison de quelque chose de complètement sans rapport avec les modifications qu’ils ont apportées. C’est essentiellement la suite de tests qui échoue en raison de problèmes de qualité médiocres, et le développeur n’a pas soumis de modifications pour faire échouer la suite de tests. C’est un test peu fiable, mal écrit, qui ne fonctionne que 90 % du temps. L’équipe existante est probablement okay avec cela – cela ne ralentit que les processus – mais l’outillage peut être obsolète et démoralisant pour quiconque se trouve en dehors de l’organisation.

C’est un exemple parmi beaucoup d’autres qui entravent la bonne DX. Une façon de prévenir cela est d’avoir un champion désigné au sein de votre équipe d’ingénierie et de développement logiciel. De nombreuses petites organisations n’ont pas de leader en matière de DX, mais les grandes et réussies oui. Ces professionnels suivent des choses comme le temps qu’il faut à un nouveau développeur pour configurer un environnement. Et si deux semaines est trop long, ils déterminent comment réduire ce temps de moitié.

Il existe des outils pour aider, comme CircleCI, avec des fonctionnalités natives qui suivront la fiabilité d’une suite de tests. Ce dont vous avez besoin, c’est quelqu’un pour prendre les rênes et s’arrêter après chaque sprint pour aborder certaines des modifications qui rendront le code plus facile à maintenir et à utiliser à l’avenir. Cela se résume à avoir un leader intéressé à améliorer la DX. Pour que cela se produise, recherchez un ingénieur de niveau senior, accompagné d’un membre du personnel relativement nouveau qui peut fournir des commentaires sur les lacunes possibles.

De plus, IDC prévoit que le marché de l’automatisation des tests de logiciels alimenté par l’IA continuera à croître à un taux de croissance annuel composé de 31,2 % jusqu’en 2027, assurez-vous donc d’exploiter pleinement cette technologie.

Métriques et signaux d’alarme

Il existe de nombreuses métriques que vous pouvez suivre lors de l’évaluation de l’impact de la dette technique sur votre équipe. Certaines des plus basiques sont le « temps de correction » ou le « temps de fonctionnalité ». Disons que vous remarquez un bogue et que vous savez comment le corriger. Certains outils peuvent suivre le temps passé de l’écriture du code à la production. Par exemple, vous seriez en mesure de voir qu’un petit correctif a pris deux jours ouvrables pour être corrigé et expédié, alors que votre équipe doit être en mesure de le faire en quelques heures. Vous pouvez également suivre des ratios, comme le nombre de correctifs de bogues par rapport aux fonctionnalités terminées.

Il existe également des moyens d’identifier les problèmes de moral qui affectent les performances de votre équipe. Les leaders de la DX peuvent effectuer des enquêtes trimestrielles pour déterminer à quel point un développeur est heureux de travailler sur un projet ou sur une partie de celui-ci. Ils peuvent creuser et demander des informations sur des domaines spécifiques comme le processus CI. Et vous pouvez toujours suivre le taux d’abandon ou de rotation dans votre équipe. Si vous remarquez que les gens partent, ils pourraient avoir l’impression que leurs préoccupations ne sont pas entendues.

Travailler avec l’outillage IA

L’essor de l’outillage IA est censé rendre les développeurs et les ingénieurs plus productifs et les produits sont expédiés plus rapidement, mais la dette technique ralentit cela. Disons que vous utilisez un outil comme GitHub ou Copilot pour aider aux modifications de code, puis que vous soumettez la demande d’extraction, et que l’intégration continue prend quelques heures pour vous répondre. Entre-temps, un développeur travaille-t-il sur autre chose ? Vérifie les e-mails ? C’est un changement de contexte et un tueur de productivité.

Les développeurs veulent travailler sur des produits où ils peuvent simplement se concentrer sur le code. L’outillage est là pour les aider à le mettre en production, et non pour constituer un obstacle constant. L’IA peut gagner du temps, mais cela dépend des équipes d’ingénierie pour définir leurs propres normes d’acceptabilité de la complexité. Pour ce faire, assurez-vous d’abord que tout code ajouté à votre branche principale a un niveau acceptable de dette technique. Avant cela, tenez une discussion ouverte et obtenez l’accord de l’équipe d’ingénierie sur le seuil acceptable de dette technique et de qualité de code. Assurez-vous que tout le monde sache que dépasser cette marque nécessite une remédiation immédiate. Une fois que vous avez défini ces normes, l’IA entre en jeu.

Il y a un cas pour les agents IA avec les ingénieurs agissant en tant qu’orchestrateurs. Une enquête menée par Capgemini auprès de 1 100 dirigeants d’entreprises a révélé que 82 % prévoient d’intégrer des agents IA dans les trois prochaines années, et qu’ils ont déjà un impact sur l’avenir du travail. Vous pourriez être en train d’examiner un rapport de bogue et de voir qu’il est suffisamment petit pour qu’un agent IA puisse le gérer de l’inception à la revue de code, ce qui économise du temps à votre équipe et la libère pour effectuer un travail plus complexe. Cependant, parfois, lorsque nous suivons ces outils de manière aveugle, il y a des compromis que l’IA a du mal à considérer.

C’est alors qu’une opinion humaine devient le facteur décisif.

Aligner la dette technique avec les objectifs

Comment aligner la réduction de la dette technique avec les objectifs que vous essayez de réaliser ou les résultats mesurables ? Cela revient à la dette technique acceptable, et parfois, dans les affaires, vous devez expédier rapidement. Vous pouvez le faire en sachant qu’un produit ne sera pas évolutif et qu’il peut y avoir des problèmes de performances à mesure que le temps passe. Souvent, un développeur fera une note pour y revenir plus tard, lorsque le moment sera venu de résoudre ces problèmes, mais cela se produit rarement. Et lorsque cette mauvaise culture prend le dessus, dans laquelle vous devez constamment expédier demain, l’impact de la dette devient évident.

Ceci est compréhensible pour une startup, mais pas pour une entreprise qui fonctionne depuis une décennie. Vous devez commencer à changer votre culture tôt et activement pour gérer la dette technique ; sinon, vous allez dépenser une fortune pour corriger les bogues de production ou vous inquiéter de la sécurité et de la conformité.

Enfin, il existe des métriques pour aider à communiquer la valeur de la réorganisation ou du remboursement de la dette technique aux parties prenantes. Le temps pourrait en être un, de l’inception à la production, ou de l’ouverture d’une demande d’extraction à la fusion et à l’expédition à la production. Un autre est le temps moyen de réparation (MTTR). Dans ce cas, vous avez peut-être trouvé un bogue ou une construction cassée, et vous mesurez le temps qu’il faut à votre équipe pour le corriger. Vous pourriez également suivre le nombre de bogues que vous avez en production. Si vous voyez que ce nombre augmente, il pourrait y avoir un problème lié à la dette technique.

Dette technique avec intérêts

Chaque organisation peut consacrer quelques heures chaque semaine pour améliorer sa DX et aider à réduire la dette technique. Si ce n’est pas le cas, vous pourriez payer plus tard, probablement par une performance lente, un ralentissement considérable de la vitesse de développement ou des problèmes de sécurité. Par exemple, votre équipe d’ingénieurs et de développeurs pourrait avoir reporté les mises à jour de Ruby on Rails pendant une décennie. Soudain, le coût d’un projet est augmenté de 500 000 dollars parce que la version de Ruby est quatre générations en retard, vous laissant avec une masse de code et des dépendances obsolètes.

Si vous aviez mis à jour progressivement, vous ne seriez pas dans cette situation. Donc, soutenez votre équipe de développement logiciel et payez au fur et à mesure. Sinon, cette dette technique reviendra vous hanter, avec intérêts.