Entrepreneuriat et écosystème technologique

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.

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.

B10 Digital Agency

Analyse des risques numériques et techniques lors de la diligence préalable à un investissement