On m’a dernièrement confié la mission de l'audit technique d’un éditeur et de son application. C’est très générique un « audit », d’autant plus lorsqu’il est réalisé par un « consultant » assez généraliste comme je le suis. Alors j’ai tâché de lister, de manière pas forcément exhaustive, les différentes étapes d'un audit technique. Une check-list qui soit à la fois générique, mais qui me permette surtout de ne rien oublier.

Avant tout : pourquoi cet audit ?

Cette première question à se poser est nécessaire car elle permet d’orienter l’étude, de définir un objectif final. En fonction de celui-ci, certains aspects de la check-list pourront être plus ou moins précisés, mis de côté, voire oubliés.

Les intentions initiales les plus courantes :

-       Un audit global, réalisé par une société consciencieuse
-       Un audit technique, pour étudier la qualité d’une application ou d’une infrastructure dans son ensemble
-       Un audit de sécurité, pour éviter des problèmes
-       Un audit réalisé dans le cadre de l’achat ou la vente d’une société

À prendre en compte : l’intelligence non-artificielle

Un facteur que l’on a tendance à mettre de côté mais qui explique l’état de l’art d’un projet, d’une application ou d’une société, est le facteur humain. Cette fameuse intelligence non-artificielle : l’intelligence humaine, à la fois si brillante et si fragile.

Quel que soit l’état de l’art de ce qui doit être audité, il est la conséquence d’une succession de décisions. Des décisions stratégiques, de crise, d’humeur ou encore politiques. Elles ont causé, jour après jour, des actions qui ont mené à bien, ou à mal, des projets. Je serai toujours surpris de voir à quel point des projets ou des sociétés en mauvaise posture ne sont que le résultat de mauvais traits de caractère humains.

Chaque décision est prise dans un contexte : fatigue, stress, deadline, pression politique... ou même talent. Mais j’ai fréquemment vu des développeurs de talent réaliser des travaux pauvres, en réponse à une perte de motivation ou à un énervement causé par l’humain, en général la hiérarchie, parfois les collaborateurs directs. J’ai vu les meilleures idées être gâchées car un responsable hiérarchique n’y croyait pas par défaut, sans même s’y intéresser.

Dans un audit, il est donc primordial de prendre en compte ces facteurs en rencontrant les différents niveaux de hiérarchie. Ils peuvent expliquer beaucoup de décisions et la connaissance du contexte peut influencer de façon non négligeable des conseils post-audit !

La checklist pour ne rien oublier

Infrastructure / Hébergement

-       Système d’exploitation (Linux, Windows par exemple)
-       Serveur applicatif (Apache par exemple)
-       Version du moteur d'exécution (PHP par exemple)
-       Serveur de base de données (MariabDB par exemple)

Pour chacun des points ci-dessus, il est primordial de vérifier :

• Licence
• Coûts associés
• Avantages et contraintes
• Pérennité
• Sécurité (à jour ?)

-       Autres logiciels / librairies installés sur le serveur
-       Annuaire des utilisateurs (AD)
-       Connexions réseau (contraintes)
-       Bande passante
-       Pare-feu 

Applications

-       Historique

• Comprendre pourquoi l’application a été construite de cette manière
• Quelles ont été les différentes étapes pour en arriver à la version actuelle ?
• Est-ce qu’il s’agit d’un code legacy repris par plusieurs personnes sur plusieurs années ?

-       Technologie utilisée

• Utilisation d’un framework, d’un CMS, est-ce du code custom ?
• Communauté : est-elle encore existante ? Sur le déclin ?
• Étude à la fois du front-end et du back-end

-       Code source (étude de la qualité)
-       Dette technique globale
-       Patterns de développement
-       Tests unitaires, fonctionnels, de non régression
-       Architecture de la base de données

• Diagrammes

-       Performance / Charge attendue

• Tests de performance
• Statistiques de visites ou d’utilisation de l'application

-       Bonnes pratiques SEO
-       Compatibilité (navigateurs, OS, mobiles)
-       Autres risques connus

 Process

-       Environnement technique

• Serveurs de développement

-       Revue de code

• Revue réalisée par des collaborateurs ? Par des externes ?
• Outils utilisés pour la réalisation de la revue de code ?

-       Intégration continue / déploiements continus

• Process mis en place ?
• Outils utilisés ?

-       Matériel informatique : est-il un frein au développement ?
-       Documentation
-       Backups, sécurité des données 

Sécurité

-       Étude de la sensibilité des données
-       De l’application

• Vulnérabilité du code source

-       De la société en général

• Sécurité des locaux
• Sécurité des machines (antivirus, pare-feu)
• Où et comment sont stockés les accès aux serveurs ?
• Bonnes pratiques rappelées aux employés

-       Chiffrement de données

Facteur humain / Gestion de projet 

-       Comprendre les enjeux et les contraintes politiques
-       Comprendre la culture de la société
-       Définition des rôles et des responsabilités de chacun
-       Comprendre comment est réalisée la gestion de projet
-       Rencontrer des développeurs et des managers
-       L’équipe fonctionne-t-elle de manière agile (Scrum, autre) ?
-       Les employés sont-ils fréquemment formés ou mis à niveau ?

Légal

-       Lieu d’hébergement des données de l’application

• Respect des lois locales
• Politique de confidentialité des données

-       Respect des lois

• GDPR, CNIL, cookies, etc.

Un audit technique, dont l’objectif final peut être très varié, ne se traduit pas que par la création d’un document précisant chaque aspect factuel et établi d’un produit ou d’une société tel un état des lieux. Le projet est de détecter les risques, les problèmes ou lacunes, mais aussi les forces. Et de prendre en considération les différentes étapes, l’historique, mais aussi les aspect politiques et humains qui ont mené à l’existant.