Analyse des risques numériques et techniques lors de la diligence préalable à un investissement
La diligence raisonnable préalable à l'investissement n'est pas seulement un processus dans lequel les états financiers, les contrats et les dossiers de l'entreprise sont examinés. Dans les…
Que contient cet article ?
La diligence raisonnable préalable à l'investissement n'est pas seulement un processus dans lequel les états financiers, les contrats et les dossiers de l'entreprise sont examinés. Dans les entreprises technologiques, une part importante de la valeur de l'entreprise peut être constituée de domaines, de logiciels, de code source, de données clients, d'infrastructures cloud, de droits de propriété intellectuelle et d'actifs numériques de marque.
Pour cette raison, la diligence numérique et technique aide les investisseurs à apprécier la capacité de croissance de l’entreprise et ses risques opérationnels et juridiques cachés.
Qu'est-ce que la due diligence numérique?
La diligence raisonnable numérique est une couche d'examen qui évalue systématiquement l'infrastructure technique de l'entreprise, la propriété numérique d'actifs, la gestion des données, les contrôles de sécurité, les dépendances logicielles et les risques en ligne.
En particulier dans les domaines de la technologie, du SaaS, du commerce électronique et des entreprises de plateformes, cet examen permet de détecter rapidement les problèmes de dette technique ou de propriété qui peuvent survenir après l'investissement.
1. Domaine et propriété numérique d'actifs
Le domaine principal de l'entreprise, les sous-domaines critiques et d'autres comptes numériques doivent être contrôlés par l'entreprise.
Sujets qui peuvent être examinés :
- le compte sur lequel le domaine est enregistré,
- qui contrôle la gestion DNS,
- si les informations de renouvellement et de récupération sont à jour,
- La propriété des comptes de médias sociaux est-elle claire,
- Sont des comptes SaaS critiques liés à l'email de l'entreprise.
2. Titularité du code source
Le code source du produit peut être l'un des actifs numériques les plus précieux de l'entreprise. Toutefois, le fait d'avoir le code dans le compte Git ne prouve pas la propriété légale.
Il convient également d'examiner comment sont réglementés les droits sur les logiciels développés dans les contrats conclus avec des employés, des fondateurs, des freelancers et des équipes de logiciels externes.
3. Modèle de dépôt et d'accès
Un dépôt de code source situé uniquement sur le compte d’un développeur externe ou d’un ancien salarié crée un risque opérationnel majeur.
La diligence peut examiner :
- Propriété des dépôts,
- les utilisateurs d'administration,
- protection des branches,
- Accès au déploiement,
- gestion des secrets
.
4. Licences Open Source
Les logiciels modernes utilisent de nombreuses bibliothèques libres. Les conditions d'octroi de licences de ces bibliothèques peuvent avoir une incidence sur le modèle commercial du produit.
Les équipes techniques et juridiques doivent examiner les licences pouvant imposer des obligations de distribution ou de partage du code source.
5. Dépendances au cloud et à l’hébergement
Il faut examiner les services en nuage dont l'entreprise est dépendante, la manière dont l'infrastructure est portable et si l'entreprise peut continuer dans des interruptions de service critiques.
Exemple de questions :
- Existe-t-il une dépendance critique à l'égard d'un seul fournisseur?
- Infrastructure en tant que code est-il utilisé?
- Des sauvegardes existent-elles ?
- Est-ce qu'un test de restauration a été effectué?
- Qui a accès à la production?
6. Dette technique
Le produit peut être en cours d'exécution, mais peut entraîner une dette technique grave.
Les versions antérieures du cadre, le manque de documentation, le manque de tests, la dépendance d'une seule personne ou les processus de déploiement complexes peuvent augmenter les coûts après investissement.
7. Sécurité de l'information
Évaluez la maturité de sécurité en fonction de la taille de l’entreprise.
Zones pouvant être contrôlées :
- utilisation de MFA,
- accès fondé sur les rôles,
- journalisation,
- sauvegardes,
- gestion des vulnérabilités,
- réponse aux incidents,
- procédures de départ des salariés.
8. Carte des données personnelles
Si l'entreprise ne sait pas quelles données personnelles elle recueille et quels sont les systèmes dans lesquels les données sont traitées, d'importants coûts de conformité peuvent survenir après l'investissement.
Le CRM, l'analyse, les systèmes de soutien, le marketing par courriel, les systèmes employés et les services cloud doivent être inclus dans la carte des données.
9. Flux de données en termes de KVKK et de RGPD
En vertu du domaine d'activité de la société, les obligations du KVKK et, le cas échéant, du RGPD doivent également être évaluées.
Plus précisément:
- processus d'information sur la vie privée,
- les finalités du traitement des données,
- leur durée de conservation,
- autorisations d’accès,
- les transferts de données à l'étranger,
- Relations avec les fournisseurs
sont des points importants à examiner.
10. L'API et les intégrations de tiers
Un produit peut dépendre de nombreux services externes. Les API de paiement, CRM, messagerie, analyse, cartographie et IA peuvent être essentielles à son fonctionnement.
Pour chaque intégration:
- à des fins commerciales,
- accès aux données,
- coût,
- autorisation,
- risque de dépendance au fournisseur
peut être évaluée.
11. Risque de réputation de marque et numérique
L'investisseur peut examiner non seulement les propres systèmes de l'entreprise, mais aussi ses risques numériques externes.
Par exemple :
- faux domaines,
- de faux comptes de réseaux sociaux,
- les litiges relatifs aux droits sur les marques,
- réclamations clients répandues,
- Résultats risqués sur Google,
- voies de vente non autorisées
peuvent affecter la valeur de l’entreprise et ses besoins opérationnels après investissement.
12. Données sur le client et les opérations
La diligence technique requise ne se limite pas à la recherche d'une vulnérabilité. Les données d'utilisation réelle du produit peuvent également être examinées.
Par exemple :
- Tendance des utilisateurs actifs,
- rétention des clients,
- attrition des clients,
- taux d'erreur du système,
- volume de tickets d’assistance,
- problèmes de produits critiques
peuvent renseigner sur la santé opérationnelle du produit.
13. Dépendance à une seule personne
Si un seul développeur détient tout le savoir sur l’environnement de production, la continuité peut être menacée après investissement.
Examinez la documentation, les procédures de déploiement, le contrôle des identifiants et le partage des connaissances.
Exemples de drapeau rouge
- Le domaine est sur le compte de l’ancienne agence plutôt que du fondateur.
- La propriété contractuelle du code source n'est pas claire.
- Les accès de production sont utilisés avec un mot de passe commun.
- Il y a une sauvegarde, mais la restauration n'a jamais été testée.
- Les clés API critiques sont conservées dans le dépôt.
- On ne sait pas à quels pays les données clients ont été transférées.
- Le produit dépend du processus de déploiement manuel connu d'une seule personne.
Que doit contenir un rapport de diligence ?
La priorité des risques et le coût des solutions devraient également être indiqués au lieu de la liste des problèmes.
Exemples de résultats :
| Zone | Risque | Niveau | Action |
|---|---|---|---|
| Domaine | Détenu sur un compte personnel | Élevé | Transférer vers un compte d’entreprise |
| Sauvegarde | Pas d'essai de restauration | Moyen | Test de récupération |
| KVKK | Carte des données manquante | Moyen | Inventaire des données |
Liste de contrôle des risques numériques avant investissement
- La propriété de domaine confirmée ?
- Le code source est-il contrôlé par l'entreprise?
- Les droits de propriété intellectuelle sont-ils réglementés par des contrats?
- Les licences open source ont-elles été révisées?
- L'accès à la production est-il documenté?
- Y a-t-il des tests de sauvegarde et de restauration ?
- Existe-t-il une carte des données personnelles?
- Les dépendances de l'API sont-elles listées?
- Les risques de réputation et de marque ont-ils été étudiés?
- Y a-t-il un processus critique qui dépend d'une personne?
L'approche B10
B10 Digital Agency examine plus que le code source et l’infrastructure. L’agence vise à évaluer Web, sécurité, intégration, données, protection de marque et réputation en ligne dans un seul inventaire.
- Développement web et infrastructure sécurisée
- Protection et surveillance de la marque
- KVKK & Conseil en conformité numérique
- Logiciel personnalisé & Application mobile
Conclusion
Les risques d’investissement ne figurent pas seulement au bilan. Une petite incertitude sur les domaines, le code, les flux de données, la sécurité, les intégrations ou les actifs de marque peut entraîner des coûts importants. La diligence numérique vise à révéler ces risques avant la transaction.
Sources et documents associés
Ces documents servent de références pour les méthodes et règles abordées dans cet article.
