Audit technique
Un audit ne sert pas à distribuer des notes. Il sert à répondre à une question que quelqu’un se pose déjà : peut-on construire la suite sur ces fondations, à quel prix, et qu’est-ce qui doit changer d’abord ?
Quand faire appel à nous
- _Vous reprenez un produit développé par une équipe ou un prestataire qui n’est plus là.
- _Vous préparez une levée de fonds et une due diligence technique est attendue.
- _Vos itérations ralentissent sans que vous sachiez précisément pourquoi.
- _Vous hésitez entre faire évoluer l’existant et repartir sur de nouvelles bases.
Ce que nous examinons
Nous examinons le socle technique d’un produit existant sur l’ensemble de sa chaîne : architecture et choix structurants, qualité et lisibilité du code, infrastructure et déploiement, sécurité, et la dette accumulée avec son coût réel.
Nous regardons aussi ce qu’une revue de code seule laisse de côté : ce qui ralentit concrètement les itérations, et la dépendance à une personne ou à un prestataire. Ces points expliquent souvent la lenteur d’un produit 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.
Ce que nous apportons
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. Cette échelle de comparaison é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.
Comment nous travaillons
Nous commençons par la question que vous vous posez, pas par le code. Un audit avant une levée, avant de reprendre un produit développé ailleurs ou 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. La qualité n’est pas une fin en soi : elle détermine la vitesse à laquelle le produit pourra encore changer de direction.
Ce que nous ne faisons pas
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.
Ce que vous obtenez
- _État des lieux argumenté : architecture, code, infrastructure, sécurité, dette
- _Risques identifiés, hiérarchisés par conséquence réelle et non par sévérité théorique
- _Recommandations arbitrées, avec l’effort et le gain attendus pour chacune
- _Trajectoire proposée : ce qui passe avant, ce qui peut attendre, ce qu’il ne faut pas faire
- _Restitution en direct avec l’équipe, pour discuter les arbitrages plutôt que les recevoir
Questions fréquentes
Un audit débouche-t-il forcément sur des travaux avec vous ?
Non. Vous repartez avec l’état des lieux, les arbitrages et la trajectoire, et vous êtes libre de les exécuter avec l’équipe de votre choix. Si vous souhaitez que nous les menions, cela relève du passage en production ou du partenariat technique.
Faut-il un audit, ou directement une mise en production ?
Si la question est « où en est mon produit et que dois-je faire », c’est un audit. Si elle est « rendez-le exploitable », c’est le passage en production : le travail commence de toute façon par un état des lieux, mais il ne s’y arrête pas.
Qui réalise l’audit ?
Les quatre associés, chacun sur son domaine : produit et design, frontend et mobile, backend et infrastructure, données et IA. Aucun junior placé, aucune sous-traitance.
Notre façon de cadrer, d’arbitrer et de nous engager est décrite en détail dans la méthode Vezero.