Comment évaluer la qualité du code livré par votre prestataire

Votre prestataire vous livre une application qui fonctionne. Les écrans s’affichent, les formulaires enregistrent, les notifications partent. Tout semble en ordre. Pourtant, six mois plus tard, chaque modification prend trois fois plus de temps, les bugs se multiplient, et un autre développeur vous annonce qu’il faut « tout reprendre depuis le début ». Ce scénario est courant, et il est évitable — à condition de savoir quoi vérifier avant qu’il ne soit trop tard.

Les cinq signaux d’alerte d’un code de mauvaise qualité

Vous n’avez pas besoin de lire du code pour repérer ces signaux. Ils sont visibles dans la façon dont votre prestataire travaille et livre.

1. Pas de tests automatisés. Quand vous demandez « comment vérifiez-vous que rien ne casse quand vous ajoutez une fonctionnalité ? » et que la réponse est « on teste à la main », c’est un drapeau rouge. Les tests automatisés ne sont pas un luxe — c’est le filet de sécurité qui empêche chaque livraison de devenir une loterie.

2. Pas de documentation. Si votre prestataire est le seul à comprendre comment fonctionne votre application, vous êtes dépendant. Une documentation technique minimale (architecture, choix techniques, procédures de déploiement) est un livrable au même titre que le code.

3. Une seule personne connaît le code. Le « bus factor » est un indicateur classique : si une seule personne disparaît et que le projet s’arrête, votre investissement est fragile. Exigez que le savoir soit partagé ou documenté.

4. Pas de gestion de versions visible. Votre prestataire devrait utiliser Git (ou équivalent) et vous donner accès au dépôt. Si vous recevez le code par e-mail ou via un dossier partagé, la traçabilité des modifications est inexistante.

5. La performance se dégrade avec le temps. Une application qui ralentit au fil des mois, sans augmentation significative du trafic ou des données, indique un code qui accumule de la dette technique — des raccourcis qui fonctionnent à court terme mais coûtent cher à long terme.

Ce que vous êtes en droit d’exiger au-delà du code

Un prestataire sérieux livre plus qu’un produit fonctionnel. Voici les livrables non négociables à inclure dans votre contrat :

Le code source et son historique. Vous payez pour le code, vous devez en être propriétaire. Cela inclut l’accès au dépôt Git avec l’historique complet des modifications, pas seulement un export final.

Les tests automatisés. Une couverture de tests d’au moins 70 % sur les fonctionnalités critiques est un standard raisonnable. Demandez le rapport de couverture — c’est un chiffre simple à comprendre.

La documentation technique. Au minimum : un schéma d’architecture, la liste des technologies utilisées, les procédures de déploiement et de sauvegarde, et un guide pour un développeur qui reprendrait le projet.

Les accès aux environnements. Serveurs, bases de données, services tiers : vous devez pouvoir accéder à tout ce qui fait tourner votre application, même si vous ne le faites jamais au quotidien.

Un rapport de sécurité. Pour toute application qui manipule des données personnelles, un scan de vulnérabilités (même basique) devrait faire partie de la livraison. C’est d’autant plus important avec les obligations de l’AI Act qui arrivent en 2026.

Auditer sans coder : les outils accessibles

Trois outils gratuits vous donnent un diagnostic lisible sans expertise technique.

SonarCloud analyse le code source et produit un tableau de bord visuel. Vous y voyez la dette technique estimée (en jours de travail pour corriger), le nombre de vulnérabilités détectées, le taux de duplication et la couverture de tests. Demandez à votre prestataire de connecter le projet — c’est gratuit pour les projets open source et abordable pour les projets privés.

Lighthouse (intégré dans Google Chrome) évalue la performance, l’accessibilité et les bonnes pratiques d’une application web. Le score de 0 à 100 est immédiatement compréhensible. Un score de performance sous 60 sur une application récente mérite des explications.

Uptime monitoring (UptimeRobot, Betterstack) mesure la disponibilité de votre application. Un taux de disponibilité sous 99,5 % sur un mois indique des problèmes d’infrastructure ou de stabilité du code.

Ces outils ne remplacent pas un audit technique complet, mais ils vous donnent des indicateurs objectifs pour une conversation éclairée avec votre prestataire.

La différence entre « ça marche » et « c’est maintenable »

La dette technique est le concept central à comprendre. C’est la différence entre un code qui fonctionne aujourd’hui et un code sur lequel vous pouvez construire demain.

Comme pour le choix entre SaaS et sur-mesure, la qualité du code est un investissement. Un code propre coûte un peu plus cher au départ, mais chaque modification future coûte moins cher. Un code de mauvaise qualité fait l’inverse : rapide à produire, ruineux à maintenir.

Le ratio de dette technique est une métrique parlante : c’est le coût estimé pour corriger tous les problèmes de maintenabilité, divisé par le coût total du développement. Au-delà de 5 %, c’est un signal d’attention. Au-delà de 20 %, vous accumulez des problèmes qui finiront par bloquer l’évolution de votre produit.

La checklist du décideur : dix questions avant de signer

1. Le code source m’appartient-il contractuellement ?
2. Ai-je accès au dépôt Git en temps réel ?
3. Des tests automatisés sont-ils écrits pour chaque fonctionnalité livrée ?
4. Une documentation technique est-elle livrée avec le code ?
5. Qui d’autre que le développeur principal peut intervenir sur le projet ?
6. Quel est le processus de déploiement (manuel ou automatisé) ?
7. Un scan de sécurité est-il réalisé avant chaque mise en production ?
8. Quel est le score Lighthouse de l’application ?
9. Comment sont gérées les sauvegardes et la reprise après incident ?
10. Que se passe-t-il si nous changeons de prestataire dans un an ?

Si votre prestataire répond clairement à ces dix questions, vous avez probablement affaire à un professionnel sérieux. Si plusieurs réponses sont floues ou esquivées, c’est le moment de creuser — avant de signer, pas après. Pour les projets d’agent IA en particulier, nous avons compilé les fourchettes de budget et les questions spécifiques à poser.

Protéger votre investissement dès le départ

La qualité du code n’est pas un sujet réservé aux développeurs. C’est un enjeu business qui détermine la durée de vie de votre investissement, votre capacité à évoluer, et votre indépendance vis-à-vis de votre prestataire.

Les outils et critères présentés ici ne demandent aucune compétence technique. Ils demandent simplement de poser les bonnes questions au bon moment — c’est-à-dire avant la signature du contrat, pas après la première facture de maintenance.