L'audit que presque tout le monde saute sur les petits deals
Demande à un acheteur ce qu'il a vérifié avant de racheter un site de contenu à 40k€ ou une boutique Shopify à 150k€, et tu entendras parler de trafic, de marges, de conditions fournisseurs. Demande-lui ce qu'il a vérifié sur la technologie qui fait tourner le business, et là, silence radio. La due diligence technique est perçue comme un truc réservé aux gros deals SaaS avec un CTO embauché pour l'occasion — pas comme quelque chose dont a besoin un acheteur solo pour un site WordPress ou une boutique Shopify.
C'est exactement dans cet angle mort que se cachent les mauvaises surprises post-acquisition. Un plugin que plus personne ne maintient. Une facture d'hébergement qui triple dès que tu dépasses un seuil de trafic que le vendeur n'a jamais mentionné. Une "intégration custom" qui s'avère être le side-project d'un freelance, non documenté et impossible à faire renouveler. Rien de tout ça n'apparaît dans un compte de résultat. Tout ça apparaît dans tes 90 premiers jours en tant que proprio.
Ce guide est une checklist technique pratique pour les acheteurs qui ne sont pas développeurs — quoi demander, quoi tester toi-même en vingt minutes, et quand ça vaut le coup de payer quelqu'un pour regarder sous le capot.
Ce que recouvre la due diligence "technique", selon le type de business
La checklist s'adapte à la plateforme. Un site de contenu sous WordPress ne porte pas les mêmes risques qu'un produit SaaS avec son propre code.
| Type de business | Risques techniques principaux |
|---|---|
| Site de contenu / affiliation | Plugins en trop, thème non maintenu, dépendance à l'hébergeur, sécurité faible (mots de passe admin faibles, pas de sauvegardes) |
| Shopify / e-commerce | Conflits entre apps, qualité du code du thème custom, personnalisations du checkout/paiement, scripts de synchro stock |
| Produit SaaS | Architecture du code, couverture de tests, dette technique, coût d'infra à l'échelle, dépendances API |
| Newsletter / communauté | Risque de migration de plateforme d'envoi, santé de la liste, automatisations custom liées au compte d'une seule personne |
Quelle que soit la plateforme, les six mêmes questions s'appliquent — juste avec plus ou moins de profondeur.
La checklist non-développeur : 6 points à vérifier avant de signer
1. Santé du code et de l'architecture. Pas besoin de savoir lire du code pour évaluer ça. Demande au vendeur : quel âge a le code, a-t-il subi une réécriture majeure, existe-t-il une doc au-delà de "ça marche, c'est tout" ? Pour un SaaS en particulier, demande si la couverture de tests existe et si les déploiements passent obligatoirement par le fondateur, ou si quelqu'un d'autre dans l'équipe peut livrer un changement. Un code que seule une personne peut toucher sans risque, c'est un risque de personne clé déguisé en problème technique. 2. Hébergement et infrastructure. Demande la vraie facture d'hébergement, pas une estimation. Demande ce qui se passe sur cette facture si le trafic ou l'usage double — certaines configs scalent linéairement, d'autres tombent d'une falaise. Vérifie si le site dépend d'un serveur unique sans redondance, et qui possède le compte d'hébergement (si c'est le compte perso du vendeur, c'est une dépendance à gérer le jour du transfert). 3. Dépendances tierces et risque API. Chaque intégration est une promesse d'une entreprise avec qui tu n'as aucun contrat. Liste toutes les API et plugins tiers dont le business dépend pour fonctionner — paiement, livraison, envoi d'email, analytics — et vérifie deux choses : l'intégration est-elle activement maintenue, et que se passe-t-il si ce fournisseur change ses prix ou ferme son offre gratuite. Un business qui dépend silencieusement d'une API obsolète est à une mise à jour près d'un checkout cassé. 4. Posture sécurité. Pas besoin d'un test d'intrusion pour un petit deal. Vérifie les bases : la double authentification est-elle activée sur les comptes admin, quand les mots de passe ont-ils été changés pour la dernière fois, existe-t-il une trace d'une brèche passée ou d'une activité de connexion inhabituelle, et — pour l'e-commerce spécifiquement — le checkout est-il conforme PCI via le processeur de paiement plutôt que de stocker les données de carte directement (la plupart des stacks Shopify et e-commerce modernes gèrent ça par défaut, mais c'est sur les checkouts custom que ça dérape). 5. Conformité des licences open-source. Si le produit est du logiciel custom, demande s'il utilise des composants open-source sous licence copyleft (type GPL) qui pourraient restreindre ta capacité à commercialiser ou modifier le code. C'est un risque marginal pour un simple site de contenu, mais bien réel pour un rachat de SaaS — un rapport d'analyse de composition logicielle, si le vendeur peut en produire un, répond à ça en quelques minutes. 6. Qui possède réellement le code. Confirme que tout développeur, freelance ou agence ayant construit le site ou le produit a signé un accord cédant la propriété intellectuelle au business — sans garder de droits personnels sur le code. C'est facile à négliger et coûteux à découvrir après la cession, quand un ancien freelance revendique la propriété d'une fonctionnalité centrale.Signaux d'alerte qui méritent une pause
| Signal | Pourquoi c'est important |
|---|---|
| Le vendeur ne peut pas dire qui d'autre pourrait modifier le site | Point de défaillance technique unique |
| Comptes d'hébergement ou de dev au nom perso, non transférables | Risque le jour du transfert, interruption de service possible |
| Pas de sauvegardes, ou sauvegardes jamais testées | Une mauvaise mise à jour et c'est la perte de données |
| Code custom sans aucune documentation | Chaque futur changement devient un pari coûteux |
| Réticence à partager les accès admin/hébergement avant la cession | Signale souvent quelque chose qu'on préfère ne pas te montrer |
Aucun de ces points ne tue automatiquement un deal. Ce sont des variables de prix et de négociation — un business avec une vraie dette technique peut rester une bonne acquisition, au bon prix et avec un vrai accompagnement du vendeur à la transition.
Pas besoin d'être développeur pour faire cet audit
Pour un site de contenu classique ou une boutique Shopify, la checklist ci-dessus, c'est surtout une conversation plus vingt minutes de test perso : connecte-toi au panel admin, vérifie la double authentification, demande la facture d'hébergement, et cherche dans la liste des plugins ou apps tout ce qui est marqué comme abandonné.
Pour un rachat de SaaS avec du vrai code custom, ça vaut le coup de payer quelques heures à un reviewer technique indépendant — quelqu'un qui n'a aucun intérêt à ce que le deal se conclue, pour avoir un avis honnête. Les plateformes freelance rendent ça accessible même pour des deals plus modestes : une revue technique ciblée d'une petite codebase coûte typiquement une fraction de ce que te coûterait une mauvaise surprise post-acquisition. Demande spécifiquement une revue de l'architecture, de la couverture de tests, du risque de dépendances et, si applicable, un contrôle des licences open-source — pas juste une "code review" générique.
Où ça se place dans ton calendrier de due diligence
- Avant la LOI : pose les six questions ci-dessus par écrit ; une réponse vague ou évasive est un signal de négociation, pas juste un motif pour fuir.
- Pendant la due diligence : demande un accès en lecture seule ou en sandbox au panel admin, au dashboard d'hébergement et au code (pour un SaaS) pour vérifier plutôt que croire sur parole.
- Au contrat de cession : mets par écrit la cession de propriété intellectuelle et les modalités de transfert d'accès — qui remet quoi, et quand.
- Les 90 premiers jours : change tous les identifiants auxquels le vendeur avait accès, mets en place tes propres sauvegardes s'il n'y en avait pas, et commence ta propre documentation au fur et à mesure que tu apprends le système, pour que le prochain proprio (même si c'est toi dans deux ans) ne reparte pas de zéro.
Questions fréquentes
Faut-il un bagage technique pour acheter un business en ligne ?Non, mais il faut une checklist et la volonté de poser des questions précises au lieu d'accepter un "ça marche très bien, t'inquiète". La plupart des vérifications ci-dessus prennent quelques minutes et ne demandent aucune compétence en code.
La due diligence technique ne concerne-t-elle que les rachats SaaS ?Non. Un site de contenu ou une boutique e-commerce porte aussi un vrai risque technique — il est juste concentré sur l'hébergement, les plugins et les accès plutôt que sur un code custom.
Combien coûte une revue technique indépendante ?Ça dépend de la taille et de la complexité du code, d'une revue légère pour un petit site à un audit plus poussé pour un SaaS mature. Demande un devis cadré avant de t'engager plutôt que de supposer un tarif fixe.
Quelle est LA question la plus utile à poser à un vendeur ?"Si tu disparaissais demain, qui d'autre pourrait se connecter et faire tourner le business ?" La réponse en dit plus long sur le risque technique que presque tout le reste de cette liste.
Est-ce un conseil juridique ou financier ?Non — c'est un panorama éducatif général pour les acheteurs qui évaluent des annonces sur Flipagora. Confirme la propriété intellectuelle, les licences et les modalités de transfert d'accès avec un professionnel qualifié avant de signer quoi que ce soit.
La due diligence technique est l'une des vérifications les moins chères à faire avant une acquisition, et l'une des plus coûteuses à sauter. Ajoute ces six questions à ton process avant d'aller voir les deals — commence par les deals Dotmarket ou les annonces Flippa si tu ne sais pas par où démarrer, et crée une alerte deals pour poser ces questions tôt, pas après être déjà tombé amoureux d'une annonce.