Le terme software audit recouvre des exercices différents selon celui qui le demande. Un acquéreur le veut avant de signer. Un client grand compte le réclame avant un contrat. Un DSI le commande pour reprendre la main sur un système devenu opaque. Dans tous les cas, la demande revient au même exercice. Regarder le logiciel comme un actif, et dire ce qu’il contient réellement. Pour un éditeur de PME comme pour une entreprise fortement digitalisée, l’exercice se prépare des mois avant qu’il ne commence, car ses conclusions se lisent dans des pièces que l’on rassemble au fil de l’eau.
La conformité des licences
Premier examen, les droits qui permettent au logiciel d’exister. L’audit liste les composants tiers et les bibliothèques embarquées, puis vérifie que chaque licence autorise l’usage qui en est fait. Un composant à licence copyleft intégré dans un produit distribué appelle une lecture attentive des obligations de publication. Les licences commerciales posent d’autres questions. Le nombre de postes couverts correspond-il au nombre de postes réels, les droits de modification et de rediffusion sont-ils détenus, les factures suivent-elles. Sur ce volet, l’auditeur rapproche ce que le produit contient de ce que l’entreprise a le droit d’en faire, et chiffre les régularisations à prévoir.
La dette technique
Deuxième examen, l’état du code lui-même. La dette technique se lit à travers des signaux concrets. Des modules réécrits plusieurs fois sans consolidation, des parties que plus personne ne sait faire évoluer, des technologies dont la communauté rétrécit, des versions arrivées en fin de support. Un framework qui ne reçoit plus de correctifs de sécurité transforme chaque ligne qui en dépend en risque différé. L’auditeur estime aussi le coût de remise à niveau, car une dette chiffrée se planifie et se discute. Pour un acquéreur, cette lecture annonce l’investissement que l’actif demandera juste après la transaction.
La sécurité du code
Troisième examen, la manière dont le logiciel résiste à un usage hostile. La revue porte sur l’authentification, la gestion des sessions et des droits d’accès, la protection des données sensibles au repos et en transit, la journalisation des événements, la configuration des serveurs. Les familles de failles les plus documentées servent de grille, injections, défauts de contrôle d’accès, mauvaises configurations. L’ANSSI publie des guides d’hygiène informatique qui donnent aux petites structures un socle de vérifications accessibles. Le volet se termine par une carte des points à durcir, hiérarchisée selon l’exposition réelle de l’entreprise.
Les dépendances open source
Quatrième examen, la chaîne de fabrication. Un produit moderne assemble des centaines de paquets tiers, chacun avec sa version, sa licence et son rythme de maintenance. L’audit dresse la liste de ces dépendances, repère celles qui ne reçoivent plus de mises à jour, celles qui portent une vulnérabilité connue, celles dont la licence impose des obligations. La démarche aboutit à un inventaire formalisé, tenable à jour à chaque mise à niveau et transmissible tel quel à un acquéreur ou à un auditeur externe. Une PME éditrice qui tient cette liste répond à l’avance à une question que la plupart des acquéreurs posent désormais.
La propriété intellectuelle du code
Cinquième examen, la titularité. Qui détient les droits sur le code, sur la base de données, sur la marque, et les écrits suivent-ils. Un développement confié à un prestataire sans clause de cession laisse les droits chez l’exécutant. Un développeur parti emporter une partie du produit crée une zone grise que l’audit documente. Une contribution externe restée sans écrit formalisé soulève la même interrogation. L’auditeur rapproche les écrits des contributions réelles et désigne les zones à sécuriser. La date du premier dépôt dans un gestionnaire de versions et la continuité de l’historique forment une preuve de création précieuse pour défendre la titularité.
Ce que l’audit apporte dans une cession
En contexte de transaction, l’audit de logiciel sert d’éclairage mutuel. L’acquéreur y lit la solidité de l’actif, la pérennité des technologies, l’étendue des droits transférés et les chantiers qui suivront la signature. Le vendeur y gagne la possibilité de corriger avant l’ouverture du dossier ce qui se corrige, une licence à régulariser, une clause de cession à signer, une dépendance à documenter. Le volet IA d’une due diligence suit la même logique de préparation, et l’article Data room et due diligence détaille ce qu’un acquéreur vérifie aujourd’hui sur les usages d’IA d’une cible. L’audit de logiciel en constitue le socle technique, la composition et la titularité du code.
Ce que l’audit apporte en mise en conformité
Hors transaction, l’audit sert à reprendre la maîtrise. Il produit une liste hiérarchisée des écarts, licences à régulariser, versions à mettre à niveau, accès à revoir, documentation à écrire. Cette liste devient un plan de remise en ordre, les sujets qui exposent l’entreprise à court terme d’abord, les chantiers de fond ensuite. Un DSI y trouve une base de discussion factuelle avec la direction, des noms de composants et des ordres de grandeur là où il y avait des impressions. Le volet gouvernance des données et des accès se prolonge dans l’article Audit IA et cybersécurité.
L’IA dans le logiciel, un périmètre qui s’élargit
Un produit qui embarque une fonction d’IA, par une API externe ou un modèle intégré, ajoute des points de vérification aux cinq examens précédents. La dépendance au fournisseur de modèle d’abord, sa stabilité technique et tarifaire, l’existence d’une alternative en cas de changement d’offre. Les données transmises ensuite, leur destination, leur durée de conservation, leur usage éventuel pour l’entraînement côté fournisseur. Les conditions d’usage des fournisseurs enfin, qui encadrent ce que le produit a le droit d’envoyer au service. Un flux d’IA absent de la cartographie échappe à chaque examen classique, la licence du paquet se lit, la destination des données se devine. L’article IA et conformité détaille les lectures que des directions générales mènent sur ces usages.
- Listez les dépendances IA de vos produits, API appelées et modèles embarqués, avec leur fournisseur.
- Documentez les données transmises à chaque service d’IA, leur destination et leur durée de conservation.
- Relisez les conditions d’usage des fournisseurs d’IA sur les données et l’entraînement.
- Ajoutez ces pièces au même dossier que vos preuves de licences, de versions et de cessions de droits.
Un logiciel audité se raconte avec des pièces. Inventaire des composants, droits détenus, flux de données tracés.
Situer votre logiciel avant l’audit
L’audit de logiciel se prépare, et la préparation commence par une lecture claire de vos outils et de vos usages. L’autodiagnostic IA Diagnostic couvre en vingt questions les outils en circulation, les données engagées, les dépendances et la gouvernance. Vous obtenez un score de maturité et trois pistes de travail adaptées à vos réponses, sans inscription. Les 245 fiches d’organisations et 142 outils analysés dans la base interne suivie par l’équipe décrivent la même réalité, les outils se multiplient plus vite que les documents qui les expliquent. Le résultat de l’autodiagnostic forme une première trace écrite, à apporter à votre auditeur, votre acquéreur ou votre DSI.