Audit technologique

Nous examinons un produit existant sur l’ensemble de sa chaîne : architecture et choix techniques structurants, qualité et lisibilité du code, infrastructure et déploiement, sécurité, dette accumulée et son coût réel, expérience utilisateur, et cohérence entre ce que le produit fait et ce qu’il est censé permettre.

Nous regardons aussi ce qu’un audit purement technique laisse de côté : la manière dont les décisions se prennent, ce qui ralentit les itérations, et la dépendance à une personne ou à un prestataire. Ce sont souvent ces points qui expliquent pourquoi un produit devient lent à faire évoluer, bien avant la qualité du code.

Le résultat n’est pas une liste de constats classés par gravité. C’est un jugement argumenté : ce qui doit être traité avant toute chose, ce qui peut attendre, ce qui n’a pas besoin d’être corrigé du tout, et ce que coûterait chaque option.

Quatre experts, plus de dix ans d’expérience chacun, couvrant la stratégie produit, le design, le frontend, le backend, la data et l’infrastructure. Un audit sérieux demande cette diversité : un problème d’architecture se lit rarement sans comprendre le produit qu’elle sert.

Nous avons audité des produits à tous les stades, du pré-seed à la licorne. Cela donne une échelle de comparaison : savoir ce qui est normal pour une v0 de six mois et ce qui ne l’est plus pour un produit qui porte du chiffre d’affaires évite les deux erreurs symétriques de l’audit : dramatiser une dette assumée, ou banaliser un risque réel.

Nous sommes aussi des praticiens, pas des observateurs. Nous construisons des produits toutes les semaines, y compris les nôtres. Une recommandation que nous formulons est une recommandation que nous saurions exécuter.

Nous commençons par la question que vous vous posez, pas par le code. Un audit avant une levée de fonds, un audit avant de reprendre un produit développé ailleurs et un audit avant un changement d’échelle ne regardent pas les mêmes choses, même sur le même produit.

Nous explicitons ensuite les choix techniques structurants que nous rencontrons, afin qu’ils puissent être remis en question sans repartir de zéro. Le quatrième pilier de notre méthode dit la même chose : la qualité détermine la vitesse à laquelle le produit pourra encore changer de direction.

Nous ne produisons pas de rapport de cent pages que personne ne lira. Un audit utile tient dans un document qu’une équipe peut parcourir en une heure et discuter le lendemain.

Nous ne recommandons pas une réécriture par défaut. C’est la conclusion la plus facile à écrire et la plus coûteuse à suivre ; elle n’est justifiée que dans une minorité de cas, et nous le disons quand ce n’est pas le cas.

Nous ne confondons pas nos préférences avec des risques. Un choix technique que nous n’aurions pas fait n’est pas un problème s’il est assumé, documenté et cohérent avec le reste. Nous signalons ce qui vous empêchera d’avancer dans six mois, pas ce qui nous aurait plu davantage.