Un processus à repenser, un système à faire évoluer ?
Racontez-nous votre situation. Un premier échange, sans engagement, suffit souvent à y voir plus clair.
Audit de code
Audit de code et d’architecture logicielle
Un regard extérieur sur la structure de votre code : ce qui tient, ce qui freine, et par où commencer. Pour les éditeurs de logiciels et les équipes de développement.
Quand
Les moments où un audit aide
Le code a grandi vite
Chaque évolution prend plus de temps que la précédente, et certaines parties du code font peur à tout le monde.
Une refonte se prépare
Avant de réécrire ou de migrer, savoir ce qui mérite d’être gardé et ce qu’il faut vraiment changer.
Une reprise ou un rachat
Vous reprenez une application, une équipe ou une entreprise, et vous voulez savoir dans quel état est le code.
L’équipe s’agrandit
De nouveaux développeurs arrivent : il faut une structure et des conventions que tout le monde peut suivre.
Périmètre
Ce que nous regardons
Nous auditons du TypeScript et du JavaScript, du PHP et du Go.
Structure et découpage
Modules, couches, responsabilités : qui dépend de quoi, et où les frontières se brouillent.
Dépendances
Bibliothèques et services externes : versions, risques, et ce qui lie le code plus qu’il ne faut.
Tests et fiabilité
Ce que les tests couvrent vraiment, et ce que l’on peut changer sans crainte.
Lisibilité et conventions
Nommage, cohérence, duplication : ce qu’un nouveau développeur comprend, ou pas.
Données et intégrations
Le modèle de données, les API et les échanges avec les autres systèmes.
Build et livraison
Comment le code est construit, vérifié et mis en production.
Déroulement
Un audit en quatre temps
La durée dépend de la taille du code : nous la fixons ensemble après le premier échange, avec un devis.
Cadrer
Un premier échange, gratuit : le périmètre, vos questions, les accès. Vous recevez un devis fixe.
Lire
Nous lisons le code et sa documentation, module par module, et notons ce que nous trouvons.
Échanger
Nous échangeons avec vos développeurs : le code ne dit pas pourquoi les choix ont été faits.
Restituer
Nous rédigeons le rapport et vous le remettons, avec ses priorités.
Le rapport
Ce que vous recevez
Un document que vos développeurs peuvent suivre et que votre direction peut lire. Chaque constat est expliqué, situé dans le code et accompagné de ce que nous proposons.
- Une synthèse d’une page, lisible par la direction
- Une carte de l’architecture telle qu’elle est aujourd’hui
- Les constats, classés par gravité, avec des exemples tirés de votre code
- Les risques : ce qui peut casser, ce qui freine l’équipe
- Des recommandations concrètes, par ordre de priorité
- Une feuille de route : les gains rapides d’abord, les chantiers de fond ensuite
Et ensuite
Après le rapport, vous choisissez
Le rapport se suffit à lui-même : vous pouvez l’appliquer sans nous. Si vous le souhaitez, nous restons à vos côtés, selon ce dont vous avez besoin.
Présentation à l’équipe
Nous présentons les constats et les priorités à vos développeurs et à la direction, et répondons aux questions.
Aide à la mise en œuvre
Revues de code et décisions d’architecture au fil du refactoring, aux côtés de vos développeurs.
Audit de suivi
Quelques mois plus tard, un second regard, plus court, pour mesurer le chemin parcouru.