Due diligence technique : les 12 points que nous auditons systématiquement

Une due diligence technique est souvent perçue comme un exercice de conformité.
Une check-list.
Un passage obligé avant une décision importante.

Dans la réalité, quand elle est mal menée, elle rassure à tort.
Quand elle est bien faite, elle révèle les vrais risques, ceux qui impactent le business, la capacité à livrer, et la pérennité du produit.

De notre côté, nous considérons la due diligence technique comme un outil d’aide à la décision, pas comme un audit théorique.
Voici les 12 points que nous auditons systématiquement, quels que soient le contexte et la taille de l’organisation.

‍

1. Architecture globale et cohérence d’ensemble

‍

Nous analysons la structure du système :

• découpage applicatif,
  
• responsabilités des composants,
  
• dépendances internes et externes,
  
• points de couplage forts.
  
  

L’objectif n’est pas de juger si l’architecture est “moderne”, mais de comprendre :

• si elle est compréhensible,
  
• si elle est maintenable,
  
• et si elle supporte l’évolution.
  
  

Une architecture complexe n’est pas forcément un problème.
Une architecture incomprise, si

‍

2. Dette technique réelle (pas celle ressentie)

‍

La dette technique est souvent évoquée, rarement objectivée.

Nous cherchons à identifier :

• les zones de code à fort risque,
  
• les choix historiques qui bloquent l’évolution,
  
• les composants obsolètes ou en fin de vie,
  
• les contournements devenus structurels.
  
  

L’enjeu est de distinguer :

• ce qui est désagréable à maintenir,
  
• de ce qui est réellement dangereux pour le produit.
  
  

3. Qualité du code et standards de développement

‍

Nous analysons :

• la lisibilité du code,
  
• la cohérence des conventions,
  
• la facilité de prise en main pour un nouvel arrivant,
  
• la présence (ou non) de règles partagées.
  
  

Un code parfait n’existe pas.
Un code illisible, en revanche, a un coût direct sur la vélocité et le recrutement.

‍

4. Stratégie de tests et couverture réelle

‍

Nous regardons :

• quels types de tests existent (unitaires, intégration, end-to-end),
  
• ce qui est réellement testé,
  
• la fiabilité des tests dans le temps,
  
• leur intégration dans le cycle de delivery.
  
  

L’absence de tests est un risque évident.
Des tests instables ou inutiles le sont tout autant.

‍

5. CI/CD et capacité de déploiement

‍

Nous auditons :

• les pipelines de build et de déploiement,
  
• la fréquence des mises en production,
  
• la capacité à déployer progressivement,
  
• les mécanismes de rollback.
  
  

Un système qui ne peut pas être déployé sereinement est un système fragile, même s’il fonctionne aujourd’hui.

‍

6. Observabilité et pilotage par les faits

‍

Nous analysons :

• les métriques réellement suivies,
  
• la capacité à détecter un incident avant les utilisateurs,
  
• les indicateurs de performance et de fiabilité,
  
• la qualité des alertes.
  
  

Sans observabilité, toute décision technique repose sur des intuitions.
C’est particulièrement critique en phase de transformation ou de migration.

‍

7. Performance et scalabilité

‍

Nous évaluons :

• les performances actuelles,
  
• les goulots d’étranglement connus,
  
• la capacité du système à absorber une montée en charge,
  
• les limites identifiées ou non.
  
  

L’objectif n’est pas d’optimiser prématurément, mais de savoir où le système cassera en premier.

‍

8. Sécurité et gestion des risques

‍

Nous auditons :

• la gestion des accès et des secrets,
  
• les dépendances externes,
  
• les pratiques de mise à jour,
  
• les risques connus et leur traitement.
  
  

La sécurité n’est pas un état, c’est un niveau de maturité.
Ce qui compte, c’est la capacité à réagir, pas l’illusion du zéro risque.

‍

9. Gestion des dépendances et de l’écosystème

‍

Nous regardons :

• les frameworks et librairies utilisés,
  
• leur vitalité,
  
• leur fréquence de mise à jour,
  
• leur criticité dans le système.
  
  

Une dépendance abandonnée ou trop spécifique peut devenir un risque industriel majeur à moyen terme.

‍

10. Organisation des équipes et rôles clés

‍

Nous analysons :

• la répartition des responsabilités,
  
• l’existence (ou non) de rôles clés identifiés,
  
• les zones de dépendance à une ou deux personnes,
  
• la capacité collective à prendre des décisions techniques.
  
  

Un système robuste porté par une organisation fragile reste un risque.

‍

11. Documentation et transmission de la connaissance

‍

Nous évaluons :

• la documentation existante,
  
• sa fiabilité,
  
• son usage réel par les équipes,
  
• la capacité à onboarder rapidement.
  
  

Une connaissance uniquement orale est un risque invisible, mais critique.

‍

12. Capacité à évoluer sans tout remettre en cause

‍

Enfin, nous cherchons à répondre à une question centrale :

Le système permet-il d’évoluer de manière incrémentale, ou chaque changement est-il un pari risqué ?

C’est souvent ce point qui détermine :

• la faisabilité d’une migration,
  
• la capacité à pivoter,
  
• ou la soutenabilité du produit dans le temps.
  
  

En conclusion

‍

Une due diligence technique utile ne cherche pas à dire si un système est “bon” ou “mauvais”.
Elle cherche à rendre les risques visibles, compréhensibles et arbitrables.

Ces 12 points permettent :

• d’objectiver les décisions,
  
• d’éviter les mauvaises surprises,
  
• et surtout de choisir une trajectoire réaliste.
  
  

La technologie n’est jamais neutre.
Mais c’est l’absence de lucidité qui coûte le plus cher.

‍