Go to Hackademy website

Comment se déroule un audit applicatif avec Synbioz ?

Martin Catty

Posté par dans les catégories sécuritéentrepriseaudit

Cet article est publié sous licence CC BY-NC-SA

La réalisation de l'audit applicatif vise à dresser un état des lieux clair quant à la maintenabilité de l'application concernée.

Simple question : vous est-il déjà arrivé pendant certains travaux qu’un artisan vous regarde d’un air catastrophé et vous dise “ça a été fait n'importe comment, il faut tout refaire.” ?

Évidemment, quand cela arrive, vous n'avez aucun moyen à votre disposition pour savoir sur quoi repose ce constat, et s'il est avéré.

Dans le domaine du numérique, c'est globalement la même chose. Vous croiserez de nombreuses agences qui vous diront avec un peu d'enrobage « il faut tout refaire  ! ».

Chez Synbioz, si ce constat doit être fait, nous voulons qu'il le soit à la lumière d'indicateurs fiables et précis, et surtout, en concertation avec nos clients.

Tout projet comporte des risques, et selon les clients, certains sont acceptables, d'autres non. L'audit applicatif permettra de déceler ces risques et de les mettre en avant pour décider de la marche à suivre.

Dans cet article, vous découvrirez les 5 phases clés du déroulement d’un audit applicatif avec Synbioz.

pour auditer la sécurité de votre système d'information <<

Étape 1 : Partager les objectifs

audit applicatif
La première étape pour un audit réussi est de partager les objectifs. C'est bien sûr le client qui les fixe en nous expliquant le contexte qui l'a amené à avoir recours à cet audit.

À noter que c'est aussi fréquemment l'inverse : quand le client nous explique sa situation, avec ses mots, nous pouvons l'orienter sur cette solution d'audit.

Les situations débouchant sur un audit peuvent être très variées. En voici quelques exemples : 

  • le client souhaite changer de prestataire,
  • l'application est lente et/ou sujette à de nombreux bugs,
  • les livraisons de nouvelles fonctionnalités sont de plus en plus longues et sujettes à régression,
  • le système d'information est un élément clé et l'entreprise est en phase de revente,
  • l'équipe en charge des développements est composée d'une ou de quelques personnes clés dont l'absence ferait peser un risque à l'entreprise,
  • le client souhaite s'assurer de la conformité de son application avec les derniers standards de sécurité,
  • par anticipation, le client veut déterminer si l'application pourra facilement évoluer pour les 5 prochaines années afin de décider de l'orientation à lui donner.

Ces objectifs divers et variés sont importants car un audit est toujours court (pas plus de 10 jours), et il est nécessaire de mettre l'emphase sur les points qui répondront aux questions les plus importantes.

Étape 2 : Échanger avec les intervenants

Nous tâchons, autant que possible, d'impliquer les acteurs en place. Il ne s'agit pas de juger, mais plutôt d'analyser et mesurer les risques pour proposer des solutions à nos clients.

Souvent, les dirigeants préfèrent intervenir sans concerter leurs équipes opérationnelles de peur de les froisser. D'expérience, nous conseillons l'inverse. Tôt ou tard, l'information circule et les équipes se sentent jugées et trahies si elles n'ont pas été prévenues.

Un audit doit se faire avec discernement. Nous en faisons d'autant preuve que notre métier est de développer des applications.

Notez que ce qui peut sembler (avec beaucoup de distance) comme absurde d'un point de vue technique, aura la plupart du temps une explication rationnelle dans le contexte de l'époque. Nous sommes tous amenés à faire des choix, et à se dire “on repassera dessus plus tard”.

Notre audit est de plus haut niveau et vise à déterminer ce qui peut réellement poser problème pour la maintenance future de l'application.

Étape 3 : Analyser sur base de processus automatiques et humains

audit-informatique

Lors de nos audits applicatifs, nous nous appuyons sur un certain nombre d'outils permettant d'extraire plusieurs métriques telles que le nombre de lignes de code, ou encore, le risque de sécurité des dépendances.

L'intérêt de ces outils est de pouvoir rapidement déterminer la taille de l'application, la version des dépendances, mais aussi, d’analyser la sécurité en surface.

Cependant, ces outils ont leurs limites, et ne nous permettent pas de savoir :

  • si l'intégration de nouvelles personnes sur le projet peut se faire sans heurt,
  • si l'architecture existante permet de facilement intégrer de nouvelles fonctionnalités,
  • la conformité à l'état de l'art,
  • et de nombreux autres éléments qui ne sont pas binaires et qui demandent une analyse plus fine et un bon niveau d'expérience.

Étape 4 : Comprendre l'historique du projet

Pour décider où l’on va, il faut savoir d'où l’on vient. Il est donc nécessaire de comprendre quelles étaient et quelles sont les équipes en place, quelles sont leurs conventions, leurs directives, ainsi que leurs points forts et points faibles.

Ces informations sont cruciales. Bien souvent, pendant nos audits, nous nous rendons compte que les personnes qui ont la meilleure vision du métier se trouvent au sein de l'équipe technique... pour la simple et bonne raison qu'elles ont implémenté ces règles.

Dans ces équipes, il est rare que tout le monde ait le même niveau de connaissance du projet. Généralement, cette connaissance se cristallise sur une ou deux personnes. C'est un élément auquel nous sommes attentifs pendant notre phase d'audit et qui fait l'objet de notre restitution.

Il est également assez rare qu'un projet fasse l'objet de conventions fortes (guidelines, structure du code, validation de l'intégration de dépendance, processus d'onboarding, revue de code). Toutes ces pratiques, qui prennent du temps au début, en font gagner sur le long terme en garantissant un niveau de qualité consistant, quels que soient les intervenants, et pendant tout le cycle de vie du projet.

Étape 5 : Restitution et aide à la décision

Vous l'avez compris, il y a de nombreux points importants dans un audit, qui va bien au-delà de l'analyse stricte du code.

Une fois les différents points du dessus synthétisés, il est temps de les restituer.

C'est pendant cette phase qu'on se félicite d'avoir défini des objectifs que l'on peut donc évaluer ensemble à la lumière du contenu de l'audit. Les décisions nécessaires s'imposent facilement quand les enjeux ont été clairement définis.



On le voit, l'audit nécessite de croiser un certain nombre de compétences pour être efficace. Il est rarement judicieux de le faire en interne car les équipes sont trop impliquées dans les projets pour avoir le recul nécessaire, et peuvent rapidement tomber dans le jugement et l’émotion.

Ce regard neuf et cette analyse approfondie sont essentiels pour pérenniser le travail de plusieurs années.

Faites-vous accompagner !

Nouveau call-to-action

Articles connexes

8 raisons pour lesquelles vous devriez mener un audit de sécurité

22/12/2020

Le système d’information (SI) est le cœur qui alimente l’ensemble des organes de votre entreprise. Il est généralement composé d’un ERP, de progiciels métiers et de logiciels développés...

Sécurité informatique en entreprise : quels enjeux ?

15/12/2020

Selon le baromètre des risques 2020 d’Allianz, les cyber incidents se positionnent pour la première fois en tête des risques que les entreprises craignent le plus. On comprend aisément pourquoi : le...

4 raisons pour lesquelles votre entreprise devrait recourir à un audit de code

01/12/2020

Il n’est pas simple de comprendre, qu’à l’instar d’autres biens, une application s’use dans le temps. Vous vous demandez certainement : “Après tout, si le code ne change pas, pourquoi cela ne...

7 règles d’or pour assurer la sécurité des systèmes d’information

17/11/2020

Et voilà, je vous parle de sécurité des systèmes d’information et vous vous retrouvez avec ce schéma en tête... :