4 types d’audit informatique pour votre entreprise

Article écrit par Marc Houssaye

Il est assez courant de procéder à un audit informatique dans les entreprises. Celui-ci peut en effet s’avérer primordial dans certaines situations telles que : 

• Quand une équipe reprend les rênes d’un projet
• Lorsqu’un outil informatique est sur le point d’être cédé
• Mais encore lorsque plusieurs années se sont écoulées et qu’il est grand temps de faire le point sur les performances de votre système informatique.

Dans cet article vous découvrirez les raisons pour lesquelles il est pertinent de réaliser un audit informatique et quels sont les 4 grands types d’audit.

Pour quelles raisons est-il pertinent de faire réaliser un audit informatique ? 

Faire appel à une entreprise extérieure permet de mobiliser des experts en mesure de vous aider à prendre du recul sur votre système d’information. Que vous n’ayez pas les compétences en interne ou que vos équipes informatiques soient trop occupées voire trop concernées pour être objectives la réalisation d’un audit par un auditeur externe est un gage de neutralité et d’exhaustivité.

Solliciter une entreprise spécialisée dans les audits informatiques permet de comprendre les impératifs que le numérique impose en termes de normes de standards et de conformités. 

Cela permet également d’en savoir plus sur la manière dont les autres entreprises organisent leur département numérique qu’elles soient dans le même secteur d’activité que le vôtre ou non. 

Enfin dans la mesure où le numérique est aujourd’hui plus qu’un levier de croissance et qu’il touche désormais aux dimensions essentielles d’une entreprise (télétravail commandes automatisation…) s’assurer de la fiabilité de son infrastructure et de ses outils est une chose décisive.

Les quatre grands types d’audit

Il existe plusieurs types d’audit informatique et chacun nécessite la participation de différents acteurs au sein de votre entreprise. Il est important de savoir identifier les problématiques rencontrées ainsi que les personnes à mobiliser pour réaliser un état des lieux sincère et conforme aux exigences actuelles en matière de qualité et de sécurité.

1/ L’audit de votre structure informatique 

Stockage de vos données hébergement de vos logiciels liaisons entre les différentes briques logicielles APIs et Webservices… Tout ne s’est pas fait en un jour et l’empilement de strates successives peut avoir eu raison de la nécessaire clarté de votre système d’information. 

Il existe pourtant des solutions pour soulager la maintenance améliorer le dialogue entre différents services voire automatiser des tâches rébarbatives. 

Auditer votre infrastructure informatique permettra d’identifier les points ralentissant (ou bloquant) le fonctionnement de vos équipes. Il ne s’agit évidemment pas de révolutionner d’un coup l’ensemble de votre SI mais de progressivement améliorer l’efficacité de vos outils informatiques tout en assurant un plan de continuité et en garantissant une adoption des utilisateurs.

2/ L’audit de votre code informatique 

Le premier risque clairement identifié concerne celui lié à l’attaque informatique. L’état des lieux de vos logiciels et applications métiers permet d’identifier les outils qui souffrent de failles de sécurité qui manquent d’optimisation ou dont la dette technique est indépassable. Tests unitaires tests fonctionnels versioning… Nous vous fournissons l’ensemble des grands commandements dignes du développement logiciel de qualité.

3/ L’audit de la gestion des données 

Vous disposez certainement d’un certain nombre de données personnelles collectées au fil des différents canaux nécessaires au bon fonctionnement de votre entreprise (canal commercial canal des utilisateurs de logiciels données internes du personnel…). 

Ces données sont-elles sûres et intègres au sein de votre système d’information ? Comment améliorer la fiabilité des données collectées ? 

Certaines données ne doivent être accessibles qu’à certaines personnes au sein de vos équipes. L’audit de la gestion des données permet notamment d’étudier et d’analyser les outils que vous avez mis en place ou de vous épauler dans la conception d’applications respectant la loi RGPD.

4/ L’audit de votre organisation

Une des dimensions malheureusement la moins étudiée lors d’un audit est l’aspect organisationnel et humain. Pourtant il n’est pas admissible qu’une entreprise soit à la merci de la démission d’une personne-clef. Il n’est pas tolérable non plus qu’un framework maison freine le recrutement de nouveaux développeurs. 

La transmission de bonnes pratiques et de l’historique métier (tout ce qui ne touche pas à la technique) doivent pouvoir s’opérer de manière fluide et transparente au sein de vos équipes. Le cléricalisme guette trop souvent le monde des développeurs. 

L’audit de votre organisation s’intéresse à la pérennité et à l’accessibilité de l’information pour s’assurer que vous maîtrisez de bout en bout vos propres outils et leur évolutivité.

Des audits pour élaborer des propositions concrètes

Rappelons-le l’objectif d’un audit est avant tout de proposer un calendrier de mise en œuvre d’actions concrètes et priorisées. 

Les solutions proposées par l’audit peuvent ainsi varier en fonction des enjeux et des stratégies d’entreprise qu’ils soient à court moyen ou long terme.

Ainsi la qualité première d’un auditeur est d’adapter son analyse de la situation informatique à la politique de votre entreprise. 

C’est pourquoi un entretien préalable est nécessaire avant d’élaborer un programme d’audit sur mesure et adapté à vos objectifs.

Les DSI doivent donc continuer à s’adapter au développement web moderne tout en pérennisant le métier face à ces changements.

Rappel sur les motifs d’architectures

Pour pouvoir réaliser une application web maintenable et donc pérenne il faut pouvoir éviter les problèmes suivants :

• Faible testabilité de la logique métier. Si cette logique est liée à la base de données et au client il sera alors très difficile d’écrire des tests automatisés qui puissent être exécutés en quelques secondes. Si tous les développeurs perdent plusieurs minutes pour vérifier que la suite de tests ne retourne pas d’erreurs c’est une perte importante de productivité.
• Paralysie technique. S’il est impossible de changer une partie de l’infrastructure sans avoir à réécrire une large portion du code l’application n’évoluera pas et sera jetée à la poubelle pour en refaire une nouvelle.
• Choix techniques erronés. Avec une mauvaise architecture il est impossible de revenir en arrière comme expliqué dans le point précédent. Si un choix technique se trouve être bloquant durant le développement revenir en arrière sera impossible et le projet devra être repris à partir de zéro.
• Duplication du code. Sans architecture cohérente la duplication de code sera inévitable. Par exemple deux éléments de l’application voudront faire la même chose mais l’architecture ne le permettra pas la duplication sera la seule solution. Il faut éviter cela à tout prix !

Il est donc vital d’avoir une équipe technique employant le bon motif d’architecture pour chaque projet.

En général quand on développe une application web on utilise une architecture trois tiers (ou trois couches) incluant : l’interface utilisateur la logique métier et l’accès aux données.

Modèle-Vue-Contrôleur (MVC)

Cela se traduit dans la pratique par le motif d’architecture MVC. Ce motif se décompose comme suit :

• Les modèles communiquent avec la base de données
• Les vues sont faites pour la présentation de l’interface utilisateur
• Les contrôleurs incluent les actions effectuées par les utilisateurs

En séparant le code d’une application web de cette manière l’accès aux données est totalement séparé du reste de l’application. Sans dépendance à l’interface utilisateur ou à la logique des actions de l’utilisateur il est bien plus simple d’écrire des tests automatisés. De plus la duplication de code sera considérablement amoindrie.

Mais ce motif n’est pas parfait. Premièrement les contrôleurs et les vues restent liés et un changement d’un côté entrainera souvent un changement de l’autre.

De plus si des changements d’infrastructure interviennent comme des modifications de base de données il faudra probablement réécrire une partie importante du code. Ces évolutions sont normalement rares mais cela arrivera sûrement à un moment ou à un autre.

Pour gagner en maintenance et en évolutivité il peut être nécessaire d’avoir une architecture où l’infrastructure n’est pas liée aux modèles.

Clean architecture

La clean architecture aussi connue sous le nom d’architecture oignon ou encore architecture hexagonale permet de résoudre ces problèmes.

Le but de ce motif d’architecture est de supprimer la dépendance de la logique métier avec les autres composants de l’application (interface utilisateur frameworks base de données infrastructure mais aussi les services externes).

Contrairement au motif MVC la clean architecture est plus abstraite et il sera alors nécessaire de constituer une équipe de développeurs dotée d’une expertise sur ce type d’architecture afin d’endiguer tout couplage indésirable.

Le modèle MVC et la clean architecture sont des concepts importants quel que soit le type d’application. Isoler la couche métier de l’infrastructure permettra de s’adapter plus facilement aux changements quels qu’ils soient.

Mais les bénéfices sont importants. En plus des avantages déjà présents avec le motif MVC les changements techniques vont pouvoir intervenir rapidement et efficacement et des choix techniques problématiques vont pouvoir être corrigés avec une perte de temps minimum.

L’architecture web moderne

Ce rappel est important dans le contexte des applications web modernes.

Les applications web ont été pendant longtemps et le sont encore fréquemment aujourd’hui des monolithes. Cela signifie que toutes les parties de l’application sont interconnectées. Mais des problèmes peuvent survenir :

• Mise en production de tout ou rien. En effet si tout est lié un petit changement sur une partie du code demande la mise à production de toutes les parties. Mais si d’autres parties ont des changements en cours la mise en production est bloquée.
• Duplication des interfaces. Dans le cas où des API ouvertes vers l’extérieur existent ce qui est souvent le cas il y a de possibles duplications d’interface. Les mêmes actions doivent être programmées pour l’API que pour l’interface utilisateur.
• Montée en charge. Certaines fonctionnalités ont tendance à avoir des besoins spécifiques pour la montée en charge. Mais avec un bloc unique la montée en charge se fait sur toutes les parties de l’application même si le besoin n’est présent que sur une seule.

Pour résoudre ces problèmes de nombreuses architectures ont vu le jour.

L’architecture frontend

Depuis le début du web dynamique les vues étaient générées par le serveur. À chaque changement d’URL il y avait un aller-retour avec le serveur. JavaScript était simplement utilisé pour les actions de l’utilisateur sans interaction avec le serveur.

Ajax

Puis est venu Ajax une architecture pour les applications web utilisant JavaScript pour faire des requêtes au serveur. Le serveur envoyait une réponse en XML ou JSON qui était utilisé pour modifier le client.

Ajax a permis à de nouvelles classes d’applications web de voir le jour notamment Google Maps. Pouvoir appeler le serveur pour modifier le client sans rechargement permet de répondre aux actions des utilisateurs bien plus rapidement.

Avec des navigateurs toujours plus puissants et avec toujours plus de fonctionnalités cette architecture est toujours utilisée même si le terme l’est beaucoup moins.

De plus en plus d’actions ont été déplacées du backend vers le frontend ce qui a eu pour effet d’ajouter beaucoup de code sur le frontend ce qui peut facilement devenir un cauchemar à maintenir sans la bonne architecture.

Single Page Applications

Quand JavaScript est utilisé pour toute l’interface utilisateur et que le serveur se contente d’être une API l’architecture se nomme Single Page Application (SPA).

Le terme signifie que le rendu par le serveur est fait juste une seule fois pour charger le code JavaScript. Il n’y a donc qu’une seule page. Le changement d’URL se fait directement depuis le code JavaScript plus besoin d’allers-retours avec le serveur.

Grâce à cette architecture l’interface utilisateur est plus réactive se rapprochant des applications natives.

Avec des clients si riches le besoin d’avoir une bonne architecture pour garder le frontend maintenable est devenu une nécessité. Le motif MVC a été adapté et on parle souvent de MV* pour les SPAs car les frameworks JavaScript les plus courants (Angular React Vue Ember) n’ont pas forcément de contrôleurs mais une autre couche similaire.

Le frontend des applications web fonctionne dans ce cas comme les applications mobiles ce qui va permettre d’éviter la duplication des interfaces et consolider l’API comme source unique pour tous les clients.

Néanmoins l’indépendance du frontend par rapport au backend n’est pas forcément bénéfique. En effet si le client a besoin d’appeler l’API très fréquemment les performances peuvent se dégrader rapidement par rapport à une application monolithique.

L’architecture backend

Avec une application monolithique l’utilisateur navigue vers une URL le backend accède à la base de données pour faire toutes les requêtes nécessaires et fait le rendu de l’interface utilisateur.

Mais avec des SPAs le backend va accéder à la base de données non pas pour faire le rendu de l’interface utilisateur mais pour renvoyer les données que le client a demandé via l’API.

Et une mauvaise architecture de l’API peut avoir des conséquences désastreuses sur les performances.

REST

L’architecture d’API la plus utilisée actuellement est REST avec un format de réponse en JSON.

REST utilise la sémantique du World Wide Web à savoir les URLs ainsi que les méthodes et les entêtes des requêtes HTTP. Par exemple récupérer la liste d’utilisateurs est aussi simple que de naviguer avec un navigateur sur l’URL https://api.monapplication.com/users.

Comme HTTP REST permet aux ressources d’être facilement mises en cache. Cela apporte des gains sensibles de performance pour des applications web où les données ne changent pas souvent. Par contre si les données changent fréquemment comme pour des applications de messagerie REST n’est pas idéal.

Il faut aussi noter que REST est simple à comprendre car tous les développeurs web connaissent HTTP donc ils comprennent REST. Cependant de nombreux cas d’usages sont laissés à interprétation ce qui a eu pour effet la création de nombreuses spécifications créant une fragmentation importante sur les bonnes pratiques à suivre.

GraphQL

Une approche alternative à REST a gagné en popularité ces dernières années : GraphQL. Architecture d’API créée par Facebook elle offre une manière flexible pour développer des APIs et propose une spécification couvrant de nombreux cas d’usages.

Contrairement à REST les requêtes GraphQL ne peuvent pas être mises en cache de part sa flexibilité. Mais dans le cas d’une application web avec beaucoup de changements de données GraphQL se révèle être bien plus utile que REST.

GraphQL étant encore relativement nouveau et très différent de REST il peut être aussi difficile de trouver des développeurs avec une expertise dessus.

Les changements d’infrastructure qui en résultent

La séparation du frontend avec le backend permet donc à chacune des deux parties d’être mise en production indépendamment.

Le frontend n’étant plus que du HTML CSS et JavaScript il n’a plus besoin d’être sur le même serveur que le backend. Cela change l’infrastructure et offre plus de libertés au backend.

En effet les différentes parties du backend peuvent être séparées en services toutes hébergées sur différents serveurs adaptés aux besoins de chaque service pour une optimisation de la montée en charge maximale.

Mais quelles sont les contreparties ?

Microservices

Les microservices sont similaires à une architecture orientée service (SOA). Le backend est découpé en plusieurs morceaux indépendants ce qui permet de faire évoluer un module sans toucher à un autre et d’allouer des ressources à certains services qui ont des demandes différentes du reste des services.

C’est une architecture utilisée par de nombreuses sociétés comme par exemple Netflix.

Mais les microservices demandent un haut niveau d’expertise car ils apportent une importante complexité et les bénéfices peuvent vite s’estomper face aux problèmes de performance et la difficulté de garder tous les services indépendants.

Function-as-a-Service ou Serverless

Avec cette architecture la décomposition du backend se fait par fonctions donc des unités encore plus petites que des services.

Les avantages et les inconvénients du serverless sont très similaires aux microservices.

Architecture hybride

Donc dans les faits garder un backend monolithique et extraire certaines fonctionnalités dans des services est une possibilité bien plus facile à réaliser qui aura tous les avantages des applications monolithiques et des microservices.

Les effets sur les DSI

Comme on peut le voir il y a eu de nombreux changements dans l’architecture des applications web pour toutes les couches. Les conséquences sur les DSI sont importantes.

Transformation des équipes

Non seulement le besoin de compétences JavaScript devient plus grand puisque le frontend devient plus important mais le besoin d’expertise aussi. Il sera donc plus difficile de recruter les bons profils.

Avec la séparation maintenant assez claire entre le frontend et le backend il serait tentant de créer des équipes séparées. Une pour le frontend et une pour le backend.

Mais c’est une tentation dangereuse. L’application web est un tout. Créer des équipes multifonctionnelles permettra de ne pas cloisonner la connaissance technique et son partage sera plus fluide. Au final l’efficacité d’équipes multifonctionnelles est bien meilleure.

Transformation de l’expérience utilisateur

Les bénéfices des bonnes pratiques pour l’architecture des applications web n’est pas seulement technique. Elle permet aussi de créer une expérience utilisateur plus raffinée et adaptée aux usages d’aujourd’hui.

Transformation de la distribution

Le développement d’applications web a été grandement simplifié grâce à la multiplication de services externes pour aider dans l’infrastructure la facturation la gestion des utilisateurs des fichiers etc.

Ces services couplés à une architecture moderne il n’a jamais été aussi simple de distribuer son application web.

Donc fini les clients lourds place au SaaS. C’est déjà le cas pour de nombreuses sociétés. C’est le moment de changer si ce n’est pas encore fait. Demain sera trop tard.

Conclusion

Les bonnes pratiques de l’architecture des applications web en 2019 sont radicalement différentes de celles d’il y a 10 ans.

Les bénéfices sont multiples. Cela procure une meilleure expérience utilisateur une pérennité plus avancée et une agilité accrue pour s’adapter aux besoins d’innovation et de transformation numérique des DSI.

Vous avez maintenant toutes les clés en main pour faire les bons choix dans vos recrutements choix d’agences et dans vos projets.