Examinez isolation, facturation, coûts d’exploitation et dépendances de transfert. Reliez les preuves techniques au projet d’acquisition et d’intégration.
Une acquisition SaaS transfère un service en fonctionnement, pas seulement du code. L’acheteur reprend des engagements clients, des dépendances, des pratiques de livraison et les connaissances des personnes qui réparent les incidents. La diligence doit examiner les hypothèses du projet : le service peut-il être exploité, intégré et développé avec l’équipe et l’investissement prévus ? Définissez ces hypothèses avant de demander l’accès aux dépôts.
Suivre un client dans tout le service
Examinez arrivée, accès, facturation, traitement des données, support et départ. Identifiez où le contexte client est appliqué et comment les accès privilégiés sont contrôlés. Échantillonnez les tâches différées, exports et intégrations en plus des requêtes interactives. Leurs responsabilités peuvent différer. Distinguez les conclusions tirées du code de celles démontrées dans un environnement convenu.
| Question | Preuves | Suite possible |
|---|---|---|
| Peut-on exploiter indépendamment ? | Propriété des comptes et dépendances fournisseurs | Plan de transfert et exercice |
| Comment évoluent les coûts ? | Charges par activité et allocation du partagé | Modèle de capacité explicite |
| Les engagements clients sont-ils tenables ? | Contraintes, support et reprise | Plan des écarts importants |
| L’intégration est-elle réalisable ? | Identité, modèles de données et contrats API | Expérience limitée avant consolidation |
Rapprocher récits technique et commercial
Demandez comment l’état d’abonnement devient un droit d’accès, comment les échecs et résiliations sont traités et comment l’usage est attribué. Les preuves techniques ne remplacent pas la diligence financière, mais révèlent certaines dépendances du revenu. Une faible facture cloud actuelle ne prouve pas non plus une bonne économie d’échelle : identifiez le travail manuel, les comptes partagés et les coûts hors périmètre.
Préparer la première période d’exploitation
Listez les personnes, permissions et tâches récurrentes nécessaires immédiatement après le transfert. Repérez les connaissances concentrées et organisez leur transmission. Séparez continuité urgente et amélioration à long terme. Une réécriture peut contredire l’objectif de rétention ; une transition compatible et limitée peut parfois mieux servir l’intégration.
- Traduire la thèse d’investissement en questions vérifiables.
- Échantillonner tout le cycle client, y compris les chemins administratifs.
- Comparer les dépendances de transfert à l’échéance.
- Livrer un registre de risques avec acceptation et hypothèses ouvertes.
La conclusion doit dire où les preuves soutiennent le projet, où un investissement complémentaire semble nécessaire et ce qui reste inconnu. Une préférence technologique ne constitue pas un obstacle à l’acquisition sans contrainte opérationnelle ou stratégique concrète.
- Due diligence technique
- Architecture SaaS multi-tenant : isolation et compromis
- Salle de données technique : préparer les preuves utiles
Questions fréquentes
Le code source suffit-il ?
Non. Les traces opérationnelles, la propriété des comptes, la facturation et les entretiens complètent l’évaluation.
Faut-il tester l’isolation des clients ?
Prévoyez une évaluation convenue selon le risque, en distinguant lecture du code, configuration et tests autorisés.
La diligence technique valide-t-elle le revenu ?
Elle examine les systèmes qui le soutiennent. Les vérifications financières et commerciales restent distinctes.
Faut-il réécrire après l’acquisition ?
Seulement après examen des contraintes, de la rétention et des objectifs d’intégration. Une amélioration progressive peut mieux convenir.
Quel livrable pour la suite ?
Un plan de continuité et d’intégration nommant accès, personnes, dépendances, risques et critères de clôture.
Transformons votre besoin en périmètre réalisable
Partagez le parcours utilisateur, les intégrations et les contraintes de lancement. Nous pouvons préparer une estimation avec hypothèses et exclusions.
Pour aller plus loin
Architecture SaaS multi-tenant : isolation et compromis
Comparez ressources mutualisées et séparées dans les données, tâches et opérations. Rendez l’isolation explicite au-delà de la seule connexion utilisateur.
Salle de données technique : préparer les preuves utiles
Préparez un inventaire indexé, des accès maîtrisés et des responsables de preuves. Réduisez les questions répétées sans exposer de secrets inutiles.
Coût de la due diligence technique : périmètre et livrables
Comparez les propositions selon les systèmes, les preuves, les accès et la profondeur du rapport. Identifiez ce qui modifie réellement le coût de la revue.