Audit technique : pourquoi évaluer les systèmes existants ?

Avant de lancer une nouvelle plateforme, de migrer vers le cloud ou d’automatiser un processus, une entreprise a intérêt à comprendre son environnement actuel. L’audit technique répond à ce besoin : il examine, sur la base d’éléments vérifiables, les applications, l’infrastructure, les pratiques et les dépendances retenues dans le périmètre.

Il ne s’agit pas de justifier systématiquement un remplacement. L’objectif est de rendre les risques et les arbitrages visibles pour décider où consacrer les ressources disponibles.

Dans quelles situations réaliser un audit ?

Des mises en production difficiles, des incidents récurrents, des coûts mal expliqués ou une connaissance concentrée entre quelques personnes sont autant de signaux à examiner. Un audit peut aussi préparer une migration, une expansion, une acquisition ou un partenariat. Pour les investisseurs et partenaires, il aide à comprendre les dépendances techniques et les points restant à vérifier, dans les limites des accès et des accords de confidentialité convenus.

Un système qui fonctionne peut lui aussi mériter un examen avant une évolution importante. Une intégration mal documentée ou un composant qui n’est plus maintenu ne commande pas forcément une refonte immédiate, mais peut peser sur le choix de la solution future.

Les points à examiner en priorité

Le périmètre dépend de la décision à prendre. Une application essentielle aux paiements peut nécessiter un examen plus approfondi de ses accès, de sa continuité et de ses interfaces qu’un outil interne peu critique. Les domaines suivants constituent une base de travail :

• Architecture et dépendances : cartographier les applications, les flux de données, les interfaces, les fournisseurs et les composants critiques ; repérer les logiciels non maintenus et les points de défaillance uniques.
• Sécurité et accès : examiner les identités, les droits, les configurations, les correctifs et les vulnérabilités connues. Préciser séparément si des tests de sécurité actifs sont prévus.
• Fiabilité et reprise : analyser les incidents, la supervision, les sauvegardes et les preuves de tests de restauration. Comparer les attentes de reprise aux capacités démontrées.
• Livraison et maintenabilité : étudier des échantillons de code, les tests, les déploiements, la documentation et la répartition des responsabilités.
• Performance et coûts : rapprocher les performances des besoins des utilisateurs et examiner l’hébergement, les licences, le support et l’effort d’exploitation, sans supposer que toute dépense est évitable.

Le Google Cloud Well-Architected Framework propose notamment des axes d’analyse sur la sécurité, la fiabilité, la performance, les coûts et les opérations. Orienté cloud, il peut néanmoins aider à formuler des questions pour d’autres environnements.

Transformer les constats en décisions

Chaque constat devrait préciser le système concerné, les éléments observés, l’impact potentiel sur l’activité, la probabilité ou l’exposition, le responsable et la prochaine action proposée. Il faut aussi signaler les hypothèses et les informations manquantes. La priorité dépend de l’impact et de l’urgence, mais aussi de l’effort et des dépendances : une liste d’alertes produite par un outil ne constitue pas, à elle seule, une feuille de route.

À titre d’exemple, si un service critique dispose de sauvegardes sans preuve récente de restauration, une première étape peut consister à définir l’objectif de reprise et à organiser un test contrôlé. Le résultat permettra ensuite de décider si les sauvegardes ou les procédures doivent évoluer. Cet exemple ne décrit pas une organisation particulière.

Quelques mesures de référence permettent ensuite de suivre les progrès. Pour une équipe de développement, la fréquence de déploiement, le délai entre une modification et sa mise en production et le temps de reprise après un déploiement échoué peuvent être utiles si leurs définitions restent cohérentes. La documentation de DORA sur les indicateurs de livraison logicielle en explique les usages. Ces mesures doivent servir à améliorer le système de travail, pas à fixer des objectifs individuels.

Conserver, améliorer ou remplacer ?

L’audit doit comparer plusieurs options réalistes, sans présumer qu’une réécriture est nécessaire. Il peut être préférable de conserver un système en corrigeant certains points, de remanier un composant, de remplacer un produit ou de retirer une application inutilisée après vérification des dépendances et des besoins liés aux données. Une migration est également envisageable, sans garantie qu’elle corrige les faiblesses existantes.

Les stratégies de migration présentées par AWS comprennent notamment le maintien, le réhébergement, la refonte et le retrait de charges de travail. Pour chaque option, estimez les coûts de mise en œuvre et d’exploitation, les perturbations, les compétences nécessaires, les bénéfices attendus, les incertitudes et les conséquences d’une absence d’action.

Comment cadrer la mission ?

1. Définir la décision et le périmètre : préciser l’objectif métier, les systèmes, les environnements, les implantations, les parties prenantes et les exclusions. Distinguer revue générale et analyse approfondie.
2. Organiser des accès sûrs : convenir des intervenants autorisés, du niveau minimal d’accès, du traitement des données, de la confidentialité, des créneaux de test et des procédures d’escalade. Les tests actifs exigent une autorisation explicite et des précautions adaptées.
3. Recueillir et vérifier les éléments : croiser entretiens et documentation avec des échantillons de configuration, de code, de supervision, d’incidents et de coûts. Consigner les éléments non examinés.
4. Exiger des livrables exploitables : demander une synthèse pour la direction, une cartographie, des constats priorisés avec leurs preuves et limites, ainsi qu’une feuille de route ordonnée avec responsables proposés et fourchettes d’effort.
5. Prévoir la suite : désigner les personnes chargées de valider les constats, d’arbitrer les corrections, de suivre leur avancement et de vérifier les changements. Programmer une nouvelle revue après une évolution majeure ou selon le niveau de risque.

Un audit technique général ne vaut pas automatiquement test d’intrusion, certification ou garantie de sécurité. Le NIST Cybersecurity Framework 2.0 peut aider à structurer les échanges sur les risques cyber ; le guide OWASP de test de sécurité web constitue une ressource distincte pour préparer des tests d’applications web.

Envisager une collaboration avec Altweeb

Les services de conseil technologique et de développement logiciel d’Altweeb s’inscrivent dans ce type de réflexion sur les systèmes existants et leurs évolutions. Selon le périmètre convenu, une revue peut éclairer une feuille de route interne ou une discussion sur l’appui au développement et le renforcement d’équipe. Avant de commencer, clients et partenaires potentiels ont intérêt à définir ensemble les accès, livrables, responsabilités et éventuelles interventions ultérieures.

Un audit utile facilite la prochaine décision : corriger, conserver ou approfondir l’analyse. Sa valeur tient aux preuves et à un plan applicable, pas au volume du rapport.

Pour approfondir ce sujet, découvrez aussi Conseil technologique et transformation digitale.