Dans notre activité, nous sommes amenés à faire régulièrement des audits de code. Planifié ou forcé, un audit a pour but de déterminer la qualité logicielle d’une base de code et de faire des préconisations pour améliorer sa santé. L’objectif de cet article est de faire un retour d’expérience sur les différentes circonstances qui mènent à la réalisation d’un tel audit.

Tout semble aller, un audit pour vérifier qu’on est sur les rails

Ce genre d’audit est le plus rare. Il est planifié par un client pour s’assurer que sa base de code respecte les bonnes pratiques de programmation. A priori aucun signe n’indique un quelconque problème dans le code mais le client a conscience de l’importance de la qualité logicielle qu’il inclut très tôt dans son processus de développement.

Dans ce contexte, un audit a pour rôle de permettre d’apporter des ajustements à la manière de coder pour limiter la dette technique et partir sur de bonnes bases pour la suite du projet. L’équipe projet peut tirer pleinement profit de ce genre d’audit car il est réalisé sereinement dans une optique d’amélioration continue.

Un audit de code avant d’envisager des grosses modifications

Ce type d’audit est planifié par un client qui vient d’acquérir, par exemple, un nouveau marché. Il dispose actuellement d’une base de code assez limitée en taille mais qui va devoir grossir assez rapidement. En général, cela s’accompagne d’un agrandissement de l’équipe et d’une accélération du rythme de développement.

Ici, un audit de code vise à faire un checkup de l’existant afin de préconiser les corrections nécessaires avant qu’il ne soit trop tard et que la dette technique ne soit irrattrapable. Il est recommandé de le planifier le plus tôt possible afin d’avoir le temps de mettre en place les améliorations nécessaires et qu’il puisse être le plus profitable possible.

Il y a des problèmes, un audit pour voir ce qui ne va pas

Cet audit n’est pas prévu, il est effectué de manière forcée suite à un trop grand nombre de dysfonctionnements. Ceux-ci peuvent par exemple être de trop nombreuses régressions, des livraisons douloureuses ou des bugs fonctionnels importants. Le client soupçonne la qualité logicielle de son produit et a donc le réflexe de demander un audit pour déterminer les sources de ses problèmes et proposer des solutions adaptées.

Le contexte n’est pas idéal pour l’équipe car ils peuvent avoir l’impression d’être contrôlés et sanctionnés. Il est donc important pour les auditeurs de bien montrer qu’ils ne viennent pas pour juger les développeurs mais simplement les aider à améliorer le projet. Avec une collaboration saine et efficace, l’équipe projet se rend compte rapidement de l’objectif de l’audit. L’idée est que celle-ci prenne en main l’audit et ses conclusions de manière à ce que la situation s’améliore dans les meilleurs délais.

Un audit pour trancher un conflit contractuel

Un audit de ce type est très difficile pour toutes les parties. Il s’agit d’un prestataire (typiquement au forfait) dont le client impose un audit pour contrôler la qualité du logiciel, sur laquelle le prestataire s’est, en général, plus ou moins engagé. Il est bien visible que, dans ce contexte, le client pourrait chercher les failles pour invoquer le contrat et infliger des pénalités au prestataire tandis que celui-ci cherchera peut-être à se défendre, et donc minimiser les conclusions de l’audit. Il peut arriver que les deux parties soient de bonne volonté et souhaitent sincèrement améliorer la qualité du code, mais cela reste une situation conflictuelle peu propice au travail serein.

Dans cette situation, le rôle des auditeurs est de rester neutres et imperméables à la situation afin de réaliser un audit de qualité qui permettra réellement d’améliorer la situation. Il est très important de comprendre le contexte et les enjeux de manière non ambiguë. Cependant, les détails contractuels ne sont pas du ressort des auditeurs et ils ne doivent absolument pas prendre partie.

Conclusion

Il existe plusieurs situations très différentes qui peuvent mener à un audit de code. En fonction du contexte, le rôle des auditeurs et l’objectif de l’audit peuvent varier. Il est très rare qu’une équipe souhaite volontairement produire du code de mauvaise qualité, cela est très souvent le fruit d’un ensemble de circonstances et d’événements, parfois subis. Par conséquent, quelle que soit la situation, nous pensons qu’un audit doit être neutre et proposer des solutions concrètes pour améliorer la situation, sans viser des individus en particulier.