Due diligence technique : ce qu'on va vérifier dans votre produit, et comment s'y préparer.

Chaque ligne a été écrite par quelqu'un : un salarié, un freelance, une agence. Pour un salarié, dans ses fonctions, la loi donne les droits à l'employeur. Pour un freelance ou une agence, il faut une cession écrite. Un associé ou un stagiaire n'est pas un salarié : il lui en faut une aussi.

À montrer : la cession de droits écrite de chaque freelance, de chaque agence et de chaque personne qui a codé sans être salariée, et les contrats de travail des développeurs salariés.

Un dépôt de code ouvert par un ancien développeur. Un domaine payé avec une carte personnelle. Ces comptes font tourner le produit, mais ils ne sont pas à la société.

À montrer : la liste des comptes (dépôt de code, hébergement, domaines, stores, comptes d'API), avec pour chacun son titulaire, qui le paie et qui l'administre.

Votre produit s'appuie sur des bibliothèques publiques et des logiciels achetés. On les utilise sous licence. On ne les possède pas. Certaines licences posent des conditions quand le logiciel est distribué.

À montrer : l'inventaire des dépendances avec la licence de chacune, et les contrats des logiciels tiers.

Le RGPD s'applique dès que votre produit traite des données de personnes. L'acheteur veut savoir lesquelles, où elles sont stockées, et qui y accède.

À montrer : la liste des données traitées, la liste des sous-traitants (hébergeur, envoi d'emails, paiement) avec leurs contrats, et la façon dont les accès sont donnés puis retirés.

Tout produit a de la dette technique. L'acheteur le sait. Ce qui l'inquiète, c'est la dette que personne n'a listée.

À montrer : la liste de la dette connue, classée par gravité, avec ce que vous comptez faire de chaque point.

Sans documentation, la connaissance est dans des têtes. Et une tête peut partir.

À montrer : un schéma d'architecture, la procédure de mise en production, et les procédures courantes : restaurer une sauvegarde, donner un accès, le retirer.

C'est souvent la question qui inquiète le plus. Si une seule personne sait déployer, le produit s'arrête quand elle s'absente.

À montrer : qui sait déployer, qui détient les mots de passe, et la preuve qu'au moins deux personnes savent le faire, avec un coffre de mots de passe au nom de la société.

Hébergement, licences, API : ces coûts reviennent chaque mois. Ils comptent dans l'idée que l'acheteur se fait du produit.

À montrer : les coûts récurrents, ligne par ligne, avec les factures.

Listez chaque compte : dépôt de code, hébergement, base de données, domaines, stores, paiement, API. Passez chacun au nom de la société, avec un administrateur de votre côté. Rangez les mots de passe dans un coffre partagé.

Retrouvez le contrat de chaque freelance et de chaque agence passés sur le produit. Vérifiez qu'il cède bien les droits. S'il manque une cession, demandez-la maintenant, tant que la relation est simple.

Ce qu'une clause de cession doit dire, et ce qu'il faut récupérer : à qui appartient le code de votre application.

Listez les bibliothèques open source, les logiciels tiers et les services appelés par le code. Notez la licence de chacun, et ce qu'il coûte chaque mois. Signalez ce qui n'est plus maintenu.

Un schéma d'architecture, sur une page. La procédure de mise en production, pas à pas. Les procédures courantes. Le test : quelqu'un qui n'a jamais vu le produit doit pouvoir déployer en les suivant.

Une faille de sécurité. Un compte qui n'est pas à vous. Une cession qui manque. Un déploiement que personne d'autre ne sait faire. Ce sont les points qu'un acheteur ne laisse pas passer. Le reste peut attendre, avec un plan écrit.

Rangez chaque pièce dans un espace partagé, par thème. Datez-la. Notez qui l'a fournie. La liste des pièces est plus bas.