Comment savoir si votre application est maintenable, sans être développeur
Quand on commande une application, on peut tout vérifier : le calendrier, le budget, les écrans. Sauf une chose, et c’est celle qui décide si l’application vivra trois ans ou six mois.
Elle s’appelle la maintenabilité. Elle n’apparaît sur aucune maquette et ne se voit pas à la livraison. Il existe pourtant un moyen simple de l’évaluer, sans aucune compétence technique.
Pourquoi elle est invisible
Prenez la gravité. Vous ne la voyez pas, vous seriez en peine de l’expliquer correctement, et pourtant vous savez avec certitude qu’elle est là : vous lâchez un objet, il tombe.
Vous ne l’observez jamais directement. Vous la lisez dans ses conséquences.
La maintenabilité fonctionne pareil. Il suffit de savoir quelle conséquence regarder.
Le test tient en une question
Toutes les applications reçoivent des bugs. Un système se met à jour, un service tiers change une règle. Le bug n’est pas le signal. Le signal, c’est ce qui se passe juste après.
Au prochain bug : est-il corrigé rapidement, et sans en créer d’autres ailleurs ?
Cette question se pose à un prestataire, à une agence, à un développeur interne, et elle vaut aussi pour du code écrit avec un assistant comme Claude Code. Elle ne dépend d’aucune technologie.
Les trois réponses possibles
| Ce que vous observez | La décision |
|---|---|
| Corrigé en quelques heures, rien d’autre ne bouge | Continuez. Votre prestataire est un actif |
| Corrigé vite, mais autre chose casse dans la foulée | Audit avant d’engager la moindre nouvelle fonctionnalité |
| Long à corriger, et la correction en amène d’autres | Faites chiffrer une reprise. Voir reprendre une application ratée |
Le deuxième cas est le plus dangereux : il ressemble au premier pendant des mois.
Le symptôme qui vient toujours en second
Plus personne n’ose publier de mise à jour. L’amélioration est prête, elle attend depuis des semaines, et elle ne sort pas parce que la dernière fois que quelqu’un a touché à quelque chose, autre chose est tombé.
Une application ne meurt pas d’un coup. Elle meurt quand le coût d’y toucher dépasse le gain attendu. Si votre dernière mise à jour date de plus de six mois sans raison commerciale, le test a déjà répondu.
Les sept mots à connaître pour ne plus vous faire balader
Vous n’avez pas à savoir coder. Vous avez à reconnaître si la personne en face entretient réellement l’application.
| Le mot | Ce qu’il veut dire | La question qui va avec |
|---|---|---|
| Régression | Quelque chose qui marchait avant et qui ne marche plus après une modification | « Comment vous détectez une régression avant moi ? » |
| Test unitaire | On vérifie une règle seule, sans lancer l’application : le calcul du prix, la règle d’annulation | « Vos tests couvrent quoi, les écrans ou les règles métier ? » |
| Test end to end | On rejoue un parcours complet, de l’ouverture de l’app jusqu’au paiement, comme un vrai utilisateur | « Combien de parcours sont rejoués avant chaque publication ? » |
| Intégration continue | La chaîne qui compile et teste toute seule, à chaque modification | « Que se passe-t-il quand elle échoue ? » |
| Couplage | Deux parties de l’app qui se tiennent, au point que toucher l’une casse l’autre | « Si on change l’écran de paiement, quoi d’autre peut bouger ? » |
| Clean architecture | Les règles métier rangées à part des écrans et de la base de données | « Changer un écran peut-il modifier un calcul ? » |
| Dette technique | Ce qui n’a pas été fait proprement et qu’on repaiera plus tard, avec intérêts | « Qu’est-ce que vous avez laissé de côté pour tenir le délai ? » |
Si les réponses arrivent en une minute et contiennent des nombres, c’est bon signe. Si elles arrivent en jargon, ce n’est pas de la maintenabilité, c’est de la présentation.
Comment nous tenons ça sur nos propres applications
L’entretien ne dépend de la disponibilité de personne. Il est planifié et il s’exécute seul, chaque semaine, sur chaque dépôt.
| Quand | Ce qui tourne |
|---|---|
| Lundi | Patrouille d’architecture : une fonctionnalité contrôlée par exécution contre le référentiel du projet |
| Mercredi | Santé du code : analyse statique, un outil qui lit le code sans l’exécuter et signale ce qui va casser |
| Jeudi | Surveillance de l’intégration continue, et réparation automatique quand elle casse |
| Avant chaque publication | 30 à 50 tests end to end rejoués, en boucle jusqu’à zéro échec |
Ce qui rend une correction propre possible
Trois choses, et elles se tiennent.
Les règles métier sont testées une par une. Ce sont les tests unitaires. On les met là où se tromper coûte cher : le calcul du prix, la règle d’annulation, les droits d’accès. Pas sur les boutons, qui changent tout le temps.
Les parcours complets sont rejoués sur des versions proches de celles qui partent en production. Un test end to end joué sur une version de développement ne prouve pas grand chose : ce n’est pas ce que vos utilisateurs installeront. C’est le détail qui sépare une suite de tests rassurante d’une suite de tests utile.
Le code est découpé fonctionnalité par fonctionnalité, avec les règles métier rangées à part des écrans et de la base de données. C’est la clean architecture. Pour vous, ça se traduit par une phrase simple : changer le design d’un écran ne peut pas modifier un calcul, et une correction reste locale.
Ce n’est pas un choix esthétique. C’est exactement ce qui permet de répondre « oui » au test de façon répétée, et pas une fois par chance.
Les produits sous cette routine : UpDrive (plus de 1 000 chauffeurs, 4,9 sur iOS), BeeDone (Top 5 Product Hunt, premiers revenus au dix-neuvième jour, 18 langues), Muse Otter et Mindowl. Les deux derniers ne sont pas encore pleinement en production, et ils suivent la même routine : elle ne dépend pas du succès commercial du produit.
Ce que vous pouvez exiger dès le devis
- Le test, écrit dans le contrat : un délai de correction pour un défaut bloquant, et l’engagement qu’une correction ne dégrade pas le reste.
- Les comptes et le code à votre nom. Un prestataire qui refuse est un prestataire dont vous ne pourrez pas partir.
- La reprise possible par un tiers. C’est la seule preuve objective qu’une architecture est propre.
- Le nombre de tests automatiques, donné en chiffre.
Ces quatre points ne coûtent rien à demander et filtrent une bonne partie du marché avant la signature. Le questionnaire de cadrage les reprend, et le périmètre d’une application livrée est détaillé sur la page application mobile.
En résumé
- La maintenabilité est invisible comme la gravité : elle se lit dans ses conséquences.
- Le test tient en une question, au prochain bug : est-il corrigé vite, et sans en créer d’autres ailleurs ?
- Le symptôme de second niveau, c’est l’arrêt des mises à jour. Plus de six mois sans bouger, sans raison commerciale, et la réponse est connue.
- Sept mots suffisent pour tenir la conversation : régression, test unitaire, test end to end, intégration continue, couplage, clean architecture, dette technique.
- Trois choses rendent une correction propre possible : des tests unitaires sur les règles métier, des tests end to end rejoués sur des versions proches de la production, et un code découpé fonctionnalité par fonctionnalité.
- Chez nous l’entretien est planifié et automatique, et 30 à 50 tests end to end tournent jusqu’à zéro échec avant chaque publication.
- Quatre exigences à écrire dans le devis : délai de correction, propriété des comptes et du code, reprise par un tiers, nombre de tests automatiques.