La Direction Technique d’Atol est régulièrement sollicitée pour mener à bien des missions d’audit d’application. Les contextes de réalisation de ces audits peuvent être assez variés et le mot « audit » peut révéler des attentes et besoins différents.

• Mais alors, de quoi s’agit-il quand on parle d’audit ?
• Quels sont les grands types d’audit ?
• Existe-t-il une trame commune entre eux ?
• Et pourquoi opter pour un audit lors de votre développement ?

# C’est quoi « un audit » ? 

Commençons par poser une définition d’un audit, celle-ci sera peut-être source à débat mais elle aura néanmoins l’intérêt d’expliquer ce qu’on entend par là dans cet article.

Un audit est l’analyse d’un applicatif existant afin de dresser un bilan (bonnes pratiques et problèmes) sur un périmètre identifié.

Généralement, l’applicatif existant représente un volume important de composants, de codes, de services, … ainsi il sera rarement possible de lire et analyser l’intégralité du code. De ce fait, pour certains aspects comme la qualité du code, il peut être nécessaire de faire le focus sur certaines portions de code identifiées avec l’équipe en charge de l’application auditée.

Il est nécessaire de définir clairement le périmètre de l’audit, de ce dernier va découler la méthodologie de travail ou encore les outils utilisés.

Le livrable d’un audit prend la forme d’un rapport indiquant les éléments mis en évidence pendant l’audit. On indique pour chacun la criticité et les risques correspondant.

# Audit Vs. diagnostic 

L’audit, comme le diagnostic, va apporter des réponses à une question.

Là où l’audit va traiter une thématique assez globale (comme la qualité logicielle), le diagnostic va cibler un problème précis (comme une lenteur sur scénario fonctionnel).

De ce fait, l’approche d’un diagnostic sera orientée autour d’informations liées au problème (logs, métriques, traces, etc) pour remonter ensuite dans le code et identifier l’origine du problème.

Dans le cas d’un audit, le point d’entrée sera plutôt le code et l’architecture globale. On partira généralement d’une vision large pour ensuite cibler l’analyse sur certaines parties de l’application.

# Plus qu’un simple état des lieux 

Nous l’avons vu, le but de l’audit est de dresser un état des lieux de l’application, cependant cela ne s’arrête pas simplement à établir un constat.

Pour chaque point d’amélioration mis en évidence dans l’état des lieux, nous évaluons le risque associé et apportons des préconisations dont la difficulté de mise en place est, elle aussi, évaluée.

L’objectif est de permettre de construire en sortie d’audit un plan d’amélioration.

C’est pourquoi, à partir des informations fournies, nous aidons l’équipe en charge de l’application à définir les actions à mener ainsi que les priorités des différents chantiers.

La priorisation nécessite des connaissances sur la mise en place de la préconisation, les compétences des intervenants et les possibilités d’intégration dans la feuille de route (charge de travail, conduite du changement, etc). C’est pourquoi elle fait l’objet d’une réflexion partagée entre l’équipe ayant mené l’audit et l’équipe en charge de l’application.

# Différents types d’audits 

Nous avons précisé qu’il existe plusieurs types d’audit, voici un petit tour, non exhaustif, de périmètres qui peuvent être traités.

• # Architecture projet 

Cela regroupe les éléments qui ne concernent pas directement le code de l’application : ce qu’il y a autour et qui joue un rôle important dans la vie d’une application. Bien que leur impact sur la qualité logicielle soit indirect, il s’agit d’éléments importants à ne pas négliger. Cela comprend par exemple :

• le processus de construction du livrable et la gestion et l’organisation des sources,
• les procédures de livraison, déploiement, installation, etc,
• la gestion de la configuration et la déployabilité de l’application,
• la présence et niveau de la documentation technique,
• l’environnement de développement et de débogage.

L’audit se base essentiellement sur une analyse humaine par l’auditeur, notamment par la prise de connaissance des procédures et documentations du projet.

• # Sécurité 

L’audit des aspects sécurité peut se faire de 2 manières : boîte blanche ou boîte noire.

L’analyse en boîte blanche consiste à une analyse du code au regard de différents référentiels de sécurité comme le Top10 OWASP.

Ce type d’analyse demande en général un temps important puisqu’elle consiste à la lecture du code de l’application (et potentiellement de certaines de ses dépendances).

L’analyse en boîte noire repose sur la mise en place d’outils tiers (tel que ZAP) qui vont scanner de manière automatisée l’application à la recherche de failles.

En mode boîte noire, l’analyse repose sur des tests au runtime de l’application, et non sur la lecture du code de l’application, il n’est pas nécessaire d’avoir accès au code pour ce type d’analyse.

Ce mode de fonctionnement peut avoir quelques limites quant à la précision des préconisations (et l’estimation des difficultés de mise en place), en effet celles-ci ne peuvent pas prendre en compte spécifiquement le code de l’application.

C’est, entre autres, pour cette raison que l’on privilégie le mode boîte blanche.

Naturellement, ces deux approches ne sont pas incompatibles. Il est tout à fait envisageable de les coupler, on parlera alors de boîte grise.

• # Architecture et qualité du code 

Il s’agit de l’analyse du code à proprement parler. Cela regroupe une analyse automatique par un outil et surtout une analyse humaine du code ; cela comprend notamment :

• l’organisation du code et l’utilisation de patterns,
• le respect des bonnes pratiques de qualité de code,
• la lisibilité et maintenabilité du code.

La difficulté sur ce périmètre est que, en matière d’architecture logicielle, il n’y a pas une seule manière d’organiser le code d’une application, il ne s’agit donc pas, ici, de regarder si l’architecture en place correspond à celle que l’on aurait choisie.

Il faut vérifier si l’architecture en place est cohérente avec le contexte de l’application (complexité, robustesse souhaitée, etc) et si elle est surtout respectée.

• # Gestion des données 

Dans ce cas, l’audit va se concentrer sur la manière dont les données sont stockées et accédées par l’application. De manière similaire à l’audit d’architecture de code, il est question de vérifier la pertinence des choix autour de la gestion des données au regard du contexte applicatif, cela comprend entre autres :

• le ou les systèmes de stockages,
• la manière dont les données sont accédées et manipulées dans l’application (requêtes de sélection et de modification),
• la modélisation des données,
• l’indexation.

Il s’agit principalement d’une analyse humaine qui va nécessiter une certaine connaissance du domaine métier pour avoir un regard critique sur la modélisation.

• # Accessibilité

L’analyse de l’accessibilité s’appuie sur différents outils permettant de vérifier la conformité vis-à-vis d’un référentiel (RGAA ou WCAG).

Des outils permettent de vérifier de manière automatisée le respect de certaines règles des référentiels, cela dit, une analyse humaine est nécessaire pour avoir un niveau d’analyse poussé.

# Une démarche d’amélioration

Demander un audit d’une application peut sembler hors de propos lorsque tout va bien. Traditionnellement, les demandes d’audit viennent après l’identification de certains problèmes pour lesquels une analyse plus globale de la situation semble nécessaire.

Cependant, je pense au contraire qu’une période de calme, hors du stress lié à des dysfonctionnements en phase d’exploitation, est un bon moment pour faire une démarche d’audit.

Cela permet à la fois de réfléchir aux priorités et au plan d’actions dans un contexte isolé des urgences d’exploitation.

Cela peut être par exemple en début ou milieu de la phase de développement de l’application. Il est plus aisé de mettre en place les actions identifiées à ce moment plutôt qu’au moment de la mise en production.

Pour ces raisons, nous voyons l’audit comme une étape qui s’inscrit dans une démarche d’amélioration et que nous la distinguons du diagnostic d’un dysfonctionnement.

L’audit nous force à prendre du recul, il nous permet de réaliser les ajustements nécessaires pour pouvoir avancer plus sereinement dans le développement de l’application.