Une application SaaS peut fonctionner correctement tout en étant dangereusement difficile à faire évoluer. Les symptômes arrivent souvent au moment où l'entreprise accélère : chaque fonctionnalité prend plus de temps, les régressions se multiplient et personne ne sait exactement quelle partie du système est critique.
Un audit technique ne consiste pas à produire un rapport de 80 pages. Il doit permettre de prendre des décisions : que faut-il corriger maintenant, que peut-on laisser vivre, et quel investissement rendra les prochains mois plus prévisibles ?
1. Comprendre le chemin de valeur
Je commence par suivre un parcours réel de l'utilisateur, de l'inscription à l'action qui crée de la valeur. Cela permet de relier les choix techniques au produit plutôt que de juger la stack dans l'absolu.
Les questions importantes sont simples :
- quelles étapes sont indispensables pour servir un client ;
- quels services et appels externes sont impliqués ;
- que se passe-t-il si un fournisseur est lent ou indisponible ;
- quelles opérations nécessitent une intervention manuelle ?
2. Cartographier l'architecture et les dépendances
Une architecture lisible n'est pas forcément sophistiquée. L'objectif est de repérer les couplages dangereux : logique métier dans les contrôleurs, accès direct à la base depuis l'interface, jobs sans reprise, ou dépendance unique à un service externe.
Je documente les frontières entre frontend, API, workers, base de données, stockage et intégrations. Cette carte devient un outil de discussion pour l'équipe et évite les refontes motivées par des préférences personnelles.
3. Mesurer la dette technique par son impact
Toute dette n'est pas urgente. Je la classe selon quatre critères : fréquence de rencontre, impact utilisateur, risque opérationnel et coût de correction. Une liste de tâches sans contexte ne permet pas d'arbitrer ; une dette reliée à des incidents ou à des semaines de delivery, oui.
Une bonne sortie d'audit contient quelques actions prioritaires, avec une estimation et un résultat attendu : réduire les erreurs de paiement, rendre un déploiement réversible ou isoler un module qui bloque l'équipe.
4. Vérifier les données et les migrations
Les données sont souvent le vrai point de fragilité d'un SaaS. Je vérifie les contraintes, les index, les volumes, les migrations en production et les procédures de restauration. Une migration qui fonctionne uniquement sur une base de test est un risque, pas une solution.
Il faut aussi savoir qui peut lire ou modifier les données sensibles, et combien de temps les sauvegardes permettent de remonter en arrière.
5. Tester la sécurité de base
L'audit couvre au minimum l'authentification, l'autorisation, la gestion des secrets, les dépendances, les logs et les endpoints d'administration. L'objectif n'est pas de promettre une sécurité parfaite, mais de supprimer les erreurs évitables avant qu'elles ne deviennent coûteuses.
Pour les produits B2B, je vérifie notamment l'isolation entre organisations, les exports, les webhooks et les accès de support.
6. Observer le système en production
Sans métriques, une équipe découvre les problèmes par ses clients. Les indicateurs essentiels sont le taux d'erreur, la latence des parcours clés, la disponibilité des dépendances et la santé des workers. Chaque alerte doit avoir un propriétaire et une action associée.
Les logs structurés et un identifiant de corrélation font souvent gagner plus de temps qu'un nouvel outil de monitoring.
7. Examiner le cycle de livraison
Je regarde comment une idée devient une version en production : revue, tests, environnements, migrations, rollback et communication. Si un déploiement dépend d'une seule personne ou d'une suite de commandes mémorisées, le risque est déjà organisationnel.
Le but n'est pas de ralentir l'équipe avec des cérémonies, mais de rendre le chemin critique répétable.
8. Identifier les frontières d'équipe
La meilleure architecture du monde ne compense pas une responsabilité floue. Qui possède l'API ? Qui valide une migration ? Qui intervient sur une erreur de paiement ? L'audit met en évidence les zones où le système dépend d'une personne clé.
C'est souvent ici qu'un accompagnement de CTO par intérim apporte de la valeur : remettre de la clarté dans les priorités et les responsabilités avant de recruter ou de réorganiser.
9. Produire une roadmap sur 30, 60 et 90 jours
Je transforme les constats en trois horizons :
- 30 jours : risques critiques, visibilité production et quick wins ;
- 60 jours : simplification des modules qui ralentissent le delivery ;
- 90 jours : évolutions d'architecture justifiées par la croissance.
Chaque action doit avoir un propriétaire, un indicateur et une définition de terminé.
10. Faire de l'audit un outil de décision
Un audit utile se termine par une conversation avec les décideurs. Faut-il investir dans la fiabilité, préparer une levée, accélérer une roadmap, sécuriser une acquisition ou structurer une équipe ? La réponse change les priorités techniques.
Si votre SaaS grandit mais que chaque changement devient imprévisible, un regard externe peut clarifier le prochain investissement. Je peux intervenir pour réaliser un audit ciblé, puis accompagner sa mise en œuvre en tant que développeur senior ou CTO de transition.