Audit du code source avant d’acheter une entreprise de logiciels au Canada

Un audit du code source avant d’acheter une entreprise de logiciels vous dit ce que vous payez vraiment. Les vérifications financières et juridiques examinent les revenus, les contrats et les registres de la société. Elles vérifient rarement si le code appartient bien à l’entreprise, s’il est sûr à exploiter et s’il pourra être maintenu une fois les fondateurs partis. Pour les fonds de capital-investissement, les entrepreneurs-acquéreurs (search funds), les acquéreurs stratégiques et les investisseurs au Canada, un court examen technique avant la clôture peut changer le prix, les conditions de la transaction ou la décision. Voici ce que couvre un bon audit et ce qu’il faut demander au vendeur.

Ce que couvre un audit du code

Un audit utile examine le code et la façon dont l’équipe travaille, pas seulement le résultat d’un outil d’analyse. Il couvre habituellement :

1. La propriété. Qui a écrit le code, si les employés et les travailleurs autonomes ont signé des ententes qui donnent les droits à l’entreprise, et si du code a été copié d’une source où il n’aurait pas dû l’être.
2. Les licences libres. Presque tous les produits utilisent des bibliothèques libres (open source). La plupart des licences sont faciles à respecter. Certaines, comme la GPL et l’AGPL, peuvent vous obliger à publier votre propre code sous la même licence si vous distribuez le produit ou, dans le cas de l’AGPL, si les utilisateurs y accèdent par un réseau. L’audit dresse la liste de toutes les licences et signale celles qui demandent un examen plus poussé.
3. La sécurité. Les bibliothèques ayant des vulnérabilités connues, les mots de passe ou les clés laissés dans le code, les contrôles d’autorisation faibles, et la façon dont les renseignements personnels sont stockés et protégés.
4. La qualité et la maintenabilité. S’il existe des tests automatisés, si un nouveau développeur pourrait compiler et déployer le produit à partir des instructions, et quelle part du code est ancienne et fragile.
5. Les personnes clés. Si un seul développeur a écrit la majeure partie du code et détient toutes les connaissances, c’est un risque à intégrer au prix ou à planifier.
6. L’architecture, les coûts et les services externes. Si le système peut suivre vos plans de croissance, ce que coûte son hébergement, de quels services externes et licences payantes il dépend, et si certaines de ces ententes prennent fin ou exigent un consentement lorsque l’entreprise change de mains.
7. Les données et la vie privée. Quels renseignements personnels le produit contient, où il est hébergé, et comment il tient compte des règles sur la vie privée auxquelles ses clients s’attendent, comme la LPRPDE ou la Loi 25 du Québec.

Points propres à une acquisition au Canada

Quelques règles canadiennes reviennent souvent. Ce sont des questions à soulever avec votre avocat ou votre conseiller fiscal, et non des conseils juridiques ou fiscaux :

1. Les employés et les travailleurs autonomes ne sont pas traités de la même façon. Selon la Loi sur le droit d’auteur, l’employeur est généralement titulaire du droit d’auteur sur le code qu’un employé écrit dans le cadre de son emploi, sauf entente contraire. Un travailleur autonome est généralement titulaire de ce qu’il écrit, à moins de l’avoir cédé par écrit. Le fait qu’une personne soit vraiment un employé ou un travailleur autonome dépend des faits, pas seulement du titre du poste. Demandez les ententes signées, surtout celles des fondateurs pour le code écrit avant la création de l’entreprise, des premiers travailleurs autonomes et des équipes à l’étranger, et vérifiez qu’une cession faite à l’étranger est valide là où vit le développeur.
2. Les droits moraux ne peuvent pas être cédés; l’auteur peut seulement y renoncer. Le droit d’auteur canadien comprend des droits moraux qui restent à l’auteur. Vérifiez si les ententes comprennent une renonciation écrite.
3. La communication de renseignements personnels pendant une transaction. La LPRPDE, ainsi que des lois semblables au Québec, en Alberta et en Colombie-Britannique, permettent de communiquer des renseignements personnels pour une transaction commerciale éventuelle, à certaines conditions : ils doivent être nécessaires à la transaction, l’acheteur doit s’engager à ne les utiliser que pour celle-ci et à les protéger, et ils doivent être remis ou détruits si la transaction n’a pas lieu. En pratique, les auditeurs ont rarement besoin de vraies données de clients. Demandez plutôt un accès en lecture seule au code et des données de test.
4. Les demandes de RS&DE. Si l’entreprise a demandé des crédits d’impôt pour la recherche scientifique et le développement expérimental (RS&DE) pour son travail de développement, demandez à votre conseiller fiscal comment ces demandes et leurs dossiers influent sur la transaction.

Comment se déroule l’audit

L’audit typique d’un produit de petite ou moyenne taille prend d’une à quatre semaines, selon la taille du code et la rapidité avec laquelle le vendeur donne accès :

1. Un accès sous entente de confidentialité. Un accès en lecture seule aux dépôts de code, à la configuration de compilation et de déploiement, et à la documentation. Si le vendeur refuse de partager tout le code, une séance d’examen supervisée ou une équipe d’examen isolée (clean team) peut convenir.
2. Des analyses automatisées. Les outils d’analyse de la composition logicielle produisent la liste de chaque composant libre et de sa licence, souvent appelée nomenclature logicielle (SBOM), ainsi que des vulnérabilités connues. D’autres outils cherchent les secrets dans le code. C’est le point de départ, pas l’audit.
3. Un examen manuel. Des ingénieurs seniors lisent les parties qui comptent le plus : la connexion et les autorisations, les paiements, le traitement des données et les fonctions principales pour lesquelles les clients paient.
4. Des entrevues. De courtes conversations avec le responsable technique sur la façon dont l’équipe développe, teste, met en production et gère les incidents.
5. Un essai de compilation. Le produit peut-il être compilé et exécuté à partir du code et des instructions seulement?
6. Un rapport écrit. Les constats classés par niveau de risque, dans un langage simple qu’un acheteur non technique peut utiliser, avec une estimation approximative du temps et du coût nécessaires pour corriger les problèmes sérieux.

Comment les constats changent la transaction

Très peu d’audits mettent fin à une transaction. La plupart en changent les conditions. Les résultats courants sont :

1. Un ajustement du prix pour le travail à faire après la clôture.
2. Une retenue ou un entiercement jusqu’à ce qu’un problème soit corrigé.
3. Des engagements précis du vendeur dans la convention d’achat (déclarations, garanties et indemnisations). Si vous souscrivez une assurance déclarations et garanties, notez qu’elle exclut habituellement les problèmes découverts pendant la vérification diligente, ce qui est une des raisons pour lesquelles les indemnisations précises comptent.
4. Des conditions à remplir avant la clôture, comme faire signer les ententes de propriété intellectuelle manquantes ou remplacer une bibliothèque dont la licence pose problème.
5. Un plan pour les 100 premiers jours.

Votre avocat décide comment intégrer ces éléments à la convention. L’audit lui donne les faits.

Les vendeurs peuvent suivre le même processus. Un vendeur qui commande un audit avant de mettre son entreprise en vente peut corriger d’abord les pires problèmes et traverse habituellement plus vite la vérification diligente de l’acheteur.

Signaux d’alarme qui justifient de ralentir

1. Aucune entente de propriété intellectuelle signée par les personnes qui ont écrit la majeure partie du code.
2. Du code GPL intégré à un logiciel que le vendeur remet à ses clients, comme des applications, des installations sur place ou des appareils, ou du code AGPL dans un produit offert en ligne, sans plan pour le gérer.
3. Des mots de passe ou des clés dans le code, ou de vraies données de clients dans des dépôts de code ou de test.
4. Aucun test automatisé, et une seule personne qui sait comment mettre le produit en production.
5. Des comptes d’hébergement, des noms de domaine ou des dépôts de code détenus personnellement par un fondateur plutôt que par l’entreprise.
6. Un incident de sécurité que le vendeur n’arrive pas à expliquer clairement.

Dix questions à poser au vendeur

1. Qui a écrit le code, et avons-nous des ententes de propriété intellectuelle signées par chaque fondateur, employé et travailleur autonome, y compris des renonciations aux droits moraux?
2. Pouvez-vous nous fournir la liste de chaque bibliothèque libre et de sa licence?
3. Le produit contient-il du code GPL ou AGPL, et comment est-il utilisé?
4. À quand remonte le dernier test de sécurité, et qu’est-il advenu de ses constats?
5. Avez-vous déjà eu un incident de sécurité ou une atteinte à la protection des données, et comment a-t-il été géré?
6. Où les données des clients sont-elles hébergées, et quels renseignements personnels le produit contient-il?
7. Un nouveau développeur pourrait-il compiler et déployer le produit à partir de votre documentation?
8. Combien de développeurs connaissent chaque partie du système, et qui reste après la vente?
9. À qui appartiennent les comptes d’hébergement, les noms de domaine et les dépôts de code, et des licences payantes ou des ententes d’API prennent-elles fin ou exigent-elles un consentement en cas de changement de contrôle?
10. Que corrigeriez-vous en premier si vous aviez six mois de plus?

Si plusieurs réponses sont floues, voilà votre liste de points à vérifier.

Notre approche

NorthSight Technologies est une firme de développement logiciel en Ontario, au Canada. Des ingénieurs seniors examinent le code, la compilation et les pratiques de l’équipe, puis rédigent un rapport en langage simple qu’un acheteur, un conseil d’administration ou un prêteur peut utiliser, avec une estimation du coût de correction des problèmes sérieux. Comme nous construisons et corrigeons des logiciels tous les jours, nous pouvons aussi faire ce travail après la clôture si vous le souhaitez. Nous ne donnons pas de conseils juridiques ou fiscaux, et nous travaillons avec votre avocat et vos conseillers financiers.

Si vous achetez une entreprise de logiciels ou y investissez et que vous voulez un audit du code avant la clôture, nous offrons un appel gratuit de 20 minutes. Vous pouvez lire comment nous travaillons et réserver l’appel sur notre page sur la revue de code sécurisée et la sécurité applicative.

Aussi publié sur LinkedIn (en anglais) →