Service:Service

Audit & modernisation

Diagnostic technique de bases de code existantes, plan de refonte progressif, migration de stack sans coupure de service.

Ce que nous livrons

Rapport d'audit détaillé
Plan de migration priorisé
Refactorisation guidée par les tests
Documentation reprise en main

RefactorMigrationTDD

Discuter de ce besoin Voir des réalisations

Une base de code qui inquiète est rarement mauvaise partout. Elle a deux ou trois endroits que personne ne veut ouvrir, et le reste va. Le problème est que ces deux ou trois endroits sont exactement ceux qu'il faut modifier pour livrer ce que le métier demande, et que la peur qu'ils inspirent se répand sur tout le reste.

Un audit sert à remplacer cette peur par une carte. Nous lisons le code, nous mesurons ce qui se mesure, nous parlons aux gens qui le maintiennent, et nous rendons un document qui dit où sont les risques, ce qu'ils coûtent et dans quel ordre les traiter. Ce document est fait pour être lu par un directeur technique comme par un dirigeant qui doit arbitrer un budget.

Comment nous travaillons

Ce que contient le rapport, et ce qu'il ne contient pas

Il contient une cartographie des dépendances, l'état des versions et leurs échéances de support, les zones à forte complexité croisées avec leur fréquence de modification, l'état de la couverture de tests là où elle compte, et une évaluation des risques de sécurité les plus directs. Chaque constat est rattaché à un fichier et à une ligne, pas à une impression.

Il ne contient pas de jugement sur les personnes. Nous avons vu assez de bases de code pour savoir que les décisions qui semblent absurdes aujourd'hui étaient presque toujours raisonnables au moment où elles ont été prises, sous une contrainte de délai que nous n'avons pas vécue. Un rapport qui humilie l'équipe en place ne sera pas appliqué, et c'est du budget perdu.

Migrer sans arrêter le service

La réécriture complète, celle où l'on repart d'une page blanche pendant que l'ancien système continue de tourner, échoue plus souvent qu'elle ne réussit. Elle échoue parce que l'ancien système continue d'évoluer pendant ce temps, et que la cible s'éloigne aussi vite qu'on avance. Nous ne la recommandons presque jamais.

Nous travaillons par étranglement progressif : on place une façade devant l'existant, on déplace une fonction à la fois derrière cette façade, et à chaque étape le système reste livrable. C'est plus lent sur le papier et beaucoup plus rapide en pratique, parce qu'on ne se retrouve jamais avec dix-huit mois de travail non livré et un comité de direction qui perd patience.

Les tests comme filet, pas comme objectif

Sur du code existant sans tests, écrire des tests unitaires avant de refactoriser est souvent impossible : le code n'est pas testable, c'est justement le problème. Nous commençons donc par des tests de caractérisation, qui figent le comportement actuel sans juger s'il est correct. Ils servent de filet : si le comportement change pendant la refactorisation, on le sait dans la minute.

Une fois le filet en place, la refactorisation devient une opération mécanique et peu risquée. C'est l'ordre qui compte. Refactoriser d'abord et tester ensuite, c'est réécrire à l'aveugle du code dont personne ne connaît plus les règles exactes, et découvrir les écarts en production trois semaines plus tard.

Ce qui amène ici

Le développeur qui connaissait le système est parti, et la reprise se fait par lecture du code.
Une version de framework ou de base de données arrive en fin de support et vous n'avez pas de plan.
Chaque livraison casse quelque chose d'imprévu, et l'équipe a pris l'habitude de livrer moins souvent.
Vous devez racheter ou céder une société et il faut une évaluation technique honnête de son logiciel.

Quand ce n'est pas la bonne prestation

Si vous avez déjà décidé de tout réécrire et que vous cherchez un rapport pour justifier cette décision, nous ne sommes pas les bons prestataires. Notre audit peut très bien conclure que votre système mérite d'être gardé et amélioré, ce qui arrive plus souvent qu'on ne le croit. Si cette conclusion vous dérange à l'avance, autant ne pas dépenser le budget de l'audit.

Nous le disons avant de commencer, pas après.

Qualité mesurée

Tests automatisés écrits pendant le développement, pas après. Revue de code obligatoire avant toute fusion, y compris sur les correctifs d'une ligne. Analyse statique branchée sur la CI : si la couverture baisse ou qu'une vulnérabilité connue apparaît, la chaîne s'arrête et personne ne passe outre.

Livraison continue

Un environnement de recette déployé à chaque fusion, une démo à la fin de chaque itération, et un tableau d'avancement que vous consultez quand vous voulez sans avoir à le demander. Les mauvaises nouvelles arrivent tôt, quand il reste du temps pour décider quoi faire.

Transfert de savoir

Nous partons du principe que vous reprendrez la main. Les décisions d'architecture sont écrites et datées, la documentation vit dans le dépôt à côté du code, et vos développeurs travaillent en binôme avec les nôtres s'ils le souhaitent. À la fin, le code, les accès et l'historique vous appartiennent.

Aller plus loin:Service[3]

Un projet en tête ? Donnons-lui vie.

Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.

Discuter de ce besoin Voir les réalisations