Audit de projet informatique : méthode, livrables et prix

Le projet fonctionne encore, mais chaque mise en production inquiète. Le prestataire historique répond lentement. Les tests sont incomplets. Une réécriture totale paraît aussi risquée que coûteuse.

Dans cette situation, la première décision ne devrait pas être « quel nouveau framework choisir ? ». Il faut d’abord établir les faits. Un audit de projet informatique sert à comprendre ce qui fonctionne, ce qui bloque et ce qu’il est raisonnable de faire ensuite.

Un bon audit ne produit pas seulement une note technique. Il doit permettre à une direction de choisir : corriger, stabiliser, reprendre progressivement, réécrire une partie ou arrêter.

Qu’est-ce qu’un audit de projet informatique ?

Un audit de projet informatique est une analyse bornée d’un logiciel et de la manière dont il est construit, livré et exploité. Il rapproche trois réalités :

• le besoin métier annoncé ;
• le système qui existe réellement ;
• la capacité de l’équipe à le faire évoluer.

Ce n’est donc pas uniquement un audit de code source. Un dépôt peut être propre alors que personne ne sait déployer. À l’inverse, une application ancienne peut rester fiable parce que ses parcours critiques sont testés, documentés et surveillés.

L’audit doit observer l’ensemble du chemin : demande métier, code, données, sécurité, déploiement, production, incidents et coût de fonctionnement.

Sept signes qu’un audit devient nécessaire

1. Les dates de livraison ne veulent plus rien dire

Chaque estimation glisse. Une correction en ouvre trois autres. Le problème n’est pas toujours la vitesse des développeurs : le périmètre, les dépendances ou le chemin de recette peuvent être devenus illisibles.

2. Une seule personne sait mettre en production

Si une absence bloque toute livraison, le projet porte un risque immédiat. Il faut documenter les accès, le pipeline, le retour arrière et les gestes manuels.

3. Les mêmes incidents reviennent

Un correctif sans analyse de cause calme la production, mais ne la stabilise pas. Des incidents répétés signalent souvent un manque de tests, de journaux ou de responsabilité claire.

4. Le métier contourne le logiciel

Les utilisateurs retournent dans Excel, échangent des fichiers par e-mail ou ressaisissent les mêmes données. Ce contournement montre que l’outil ne couvre plus le travail réel, même s’il est techniquement « en ligne ».

5. Le coût de maintenance devient impossible à expliquer

Une facture augmente sans backlog lisible, sans niveau de service et sans distinction entre correction, évolution et exploitation. Un contrat de TMA utile doit rendre le run compréhensible.

6. Vous préparez un changement de prestataire

Changer d’équipe sans carte du système déplace le problème. L’audit permet de préparer les accès, les connaissances et les priorités avant le transfert.

7. Quelqu’un propose de tout réécrire

La réécriture peut être justifiée. Mais elle doit répondre à un blocage démontré : sécurité impossible à corriger, technologie non maintenue, architecture incapable de porter le métier ou coût de modification devenu excessif.

• CorrigerLe socle tient. Quelques blocages précis empêchent de livrer.
• StabiliserTests, déploiement, supervision et documentation avant de reprendre les évolutions.
• ReprendreUn flux à la fois, sans remplacer tout le système en une seule bascule.
• Réécrire ou arrêterSeulement si les faits montrent que conserver coûte plus cher ou maintient un risque inacceptable.

Ce que l’audit doit examiner

Le besoin métier

Quels parcours doivent absolument fonctionner ? Qui décide qu’une livraison est acceptable ? Quels contournements les équipes utilisent-elles aujourd’hui ? Sans ces réponses, l’audit risque d’optimiser une partie du logiciel que personne n’utilise.

L’architecture et le code

L’objectif n’est pas de noter chaque fichier. Il faut identifier les composants actifs, les dépendances critiques, le code mort, les versions non maintenues et les zones qu’une modification rend dangereuses.

Une analyse technique doit aussi répondre à une question simple : un nouveau développeur peut-il comprendre où intervenir sans demander l’autorisation à une seule personne ?

Les données et les accès

Où sont les données ? Qui peut les lire ou les modifier ? Les comptes d’anciens collaborateurs sont-ils fermés ? Les secrets sont-ils stockés correctement ? Les sauvegardes sont-elles restaurables ?

Pour un traitement soumis au RGPD ou à une contrainte de souveraineté, la région d’hébergement et les accès à distance doivent être écrits avec le client. Une mention « cloud européen » ne suffit pas.

Les tests et la recette

Il n’est pas nécessaire d’avoir des milliers de tests. Il faut protéger les parcours qui coûtent réellement lorsqu’ils cassent : connexion, commande, paiement, calcul, import ou transmission à un autre système.

L’audit vérifie également qui réalise la recette et sur quel environnement. Des tests automatiques sans propriétaire métier ne garantissent pas que le bon problème est testé.

Le déploiement et la production

Comment une version arrive-t-elle en production ? Peut-on revenir en arrière ? Les environnements sont-ils séparés ? Les journaux permettent-ils de comprendre un incident ? Une supervision minimale existe-t-elle ?

Une application ne devient pas fiable parce qu’elle a été déployée une fois. Il faut que quelqu’un d’autre puisse répéter l’opération proprement.

L’organisation

Qui possède le produit ? Qui arbitre le périmètre ? Qui répond lors d’un incident ? Où se trouve la documentation qui compte ? Une architecture correcte ne compense pas des décisions impossibles à prendre.

Le coût de fonctionnement

L’audit doit distinguer :

• le coût d’hébergement et des services tiers ;
• la maintenance corrective ;
• les évolutions ;
• la surveillance et les interventions ;
• les licences ;
• le coût des opérations encore manuelles.

Le chiffre parfait n’existe pas. Une estimation explicable est déjà une base de décision beaucoup plus utile qu’un forfait opaque.

Les livrables à exiger

Un rapport de cinquante pages n’est pas forcément un bon livrable. À la fin, la direction doit disposer de documents utilisables :

1. Une cartographie courte : applications, données, dépendances, environnements et responsables.
2. Une liste de risques classés : impact, probabilité, urgence et action proposée.
3. Les décisions immédiates : accès à fermer, sauvegarde à vérifier, livraison à geler ou incident à traiter.
4. Un plan sur 90 jours : ordre des travaux, résultat attendu et personne responsable.
5. Une estimation de build et de run : coût de reprise et coût mensuel prévisible.
6. Une recommandation claire : conserver, corriger, reprendre, remplacer ou arrêter.

Chaque recommandation doit être reliée à un fait observé. « Moderniser la stack » n’est pas une décision. « La version utilisée ne reçoit plus de correctif de sécurité et bloque la prochaine mise à jour » en est une.

Combien coûte un audit informatique ?

Le prix dépend surtout du périmètre :

• une application ou plusieurs ;
• un dépôt accessible ou dispersé ;
• une production documentée ou inconnue ;
• des interlocuteurs disponibles ou non ;
• une analyse technique seule ou également métier, sécurité et run.

Demandez un forfait associé à des livrables, pas un nombre de jours sans résultat défini. Le prestataire doit annoncer ce qui est inclus, les accès nécessaires et les situations qui pourraient élargir le périmètre.

Chez IT Empower Solutions, la plupart des diagnostics IT restent sous 2 000 €. Un SI multi-applications ou des accès difficiles peuvent dépasser cette fourchette : nous le disons avant de commencer.

Combien de temps faut-il prévoir ?

Une application isolée, avec un dépôt propre et les bons interlocuteurs, peut être examinée en quelques jours. Un système composé de plusieurs applications, sans documentation et avec des accès lents, demande davantage.

La durée n’est pas un argument commercial à réduire artificiellement. Ce qui compte est de savoir quand les premières décisions urgentes seront disponibles et quand le plan complet sera remis.

Corriger, reprendre ou réécrire ?

Corriger convient lorsque le système reste compréhensible et que quelques défauts identifiés bloquent la livraison.

Stabiliser puis maintenir convient lorsque l’application sert encore, mais que les tests, le déploiement ou la supervision sont trop fragiles.

Reprendre progressivement convient lorsque certaines parties tiennent et que d’autres doivent être remplacées. On protège un parcours, on livre, puis on avance vers le suivant.

Réécrire devient raisonnable lorsque la base ne peut plus être sécurisée ou maintenue à un coût acceptable. Il faut alors prévoir la migration des données, la coexistence temporaire et le retour arrière.

Arrêter est aussi une décision. Un composant peu utilisé, coûteux et redondant ne mérite pas toujours une nouvelle équipe.

L’article sur la reprise d’un projet IT bloqué détaille l’étape qui suit lorsque la reprise est retenue.

Les erreurs qui rendent un audit inutile

• Chercher un coupable au lieu d’établir les faits.
• Auditer le code sans parler au métier.
• Donner un accès administrateur général alors qu’une lecture suffit.
• Confondre préférence technologique et risque réel.
• Produire cent recommandations sans ordre ni responsable.
• Promettre une réécriture avant d’avoir mesuré le système existant.
• Ne pas chiffrer le run de la solution proposée.

Un audit utile réduit l’incertitude. S’il laisse la direction avec davantage de jargon et aucune décision, il a manqué son objectif.

Checklist avant d’ouvrir les accès

• Accord de confidentialité signé si nécessaire.
• Périmètre et livrables écrits.
• Dépôt de code accessible en lecture.
• Liste des environnements et services tiers.
• Documentation existante rassemblée, même incomplète.
• Interlocuteur métier et interlocuteur technique identifiés.
• Comptes temporaires, nominatifs et limités.
• Accès de production évité ou tracé lorsqu’il est indispensable.
• Date de restitution fixée.
• Format du plan d’action accepté.

L’objectif n’est pas de rendre le projet parfait en une semaine. Il est de remplacer les suppositions par une carte, des priorités et une décision que l’équipe peut réellement exécuter.