Comment évaluer le travail d’une agence de développement sans lire le code

En résumé : pour évaluer le travail d'une agence de développement sans lire le code, notez chaque livrable face à des critères d'acceptation écrits avant le sprint : livré, partiellement livré ou non livré, preuve à l'appui. Faites tester par votre côté, pas par l'agence, et exigez des rapports factuels par livrable. Voici la méthode, un cas réel et les signaux qui montrent qu'un projet dérive.

Le problème : vous payez un travail que vous ne pouvez pas juger

Le compte rendu vient de ceux qui font le travail. Il devient rassurant plutôt que factuel, et vous découvrez l'écart réel à la recette, quand il coûte cher. Un cas réel : sur un chantier de 90 000 $, six sprints plus tard, tous les rapports étaient au vert. Confrontés aux critères d'acceptation écrits, trois sprints sur six étaient seulement partiellement livrés : le prestataire présentait le cas nominal et repoussait la gestion des erreurs, les droits d'accès et la migration des données vers une phase absente du contrat. Repéré au sprint six, cela s'est renégocié sans coût. À la recette, cela devenait un avenant à cinq chiffres élevés.

La méthode en cinq étapes

1. Écrire les critères avant le sprint. Rédigés après, ils décrivent ce qui a été construit. Des exemples dans comment rédiger un cahier des charges.
2. Noter chaque livrable : livré, partiellement livré, non livré. Une note sans preuve est une opinion.
3. Tester côté métier. Quand les développeurs testent leur propre travail, ils testent ce qu'ils avaient anticipé. Une demi-journée par version suffit souvent.
4. Demander un rapport par livrable, avec un pourcentage et le reste à faire, au même format et au même rythme chaque fois.
5. Décider à chaque version : mise en production ou non, par écrit.

Cinq signaux d'alerte à surveiller

• le reporting passe de factuel à qualitatif (« ça avance bien ») ;
• les questions du prestataire restent sans réponse plus d'une semaine ;
• le périmètre grandit sans nouveau chiffrage de délai et de budget ;
• les tests sont faits par ceux qui ont développé ;
• personne ne sait ce qui se passe si le prestataire s'arrête (pas d'accès au code, pas de documentation).

Ce sont des problèmes de gouvernance, non de technique : ils se corrigent en quelques semaines, sans rien réécrire, à condition de les traiter tant qu'ils sont des signaux et pas encore des faits. Voir aussi les cinq signaux d'un projet qui dérape.

Vérifier ce qui est entre vos mains

• Le dépôt de code, l'hébergement et la base de données sont-ils à votre nom ?
• Pouvez-vous accéder à tout sans demander la permission ?
• Existe-t-il une documentation permettant à un nouveau développeur de lancer le projet en une journée ?

Lors d'une revue technique, le code était meilleur que prévu, mais un seul prestataire détenait les seuls accès à la base de production et au déploiement, et n'était plus payé depuis sept semaines. C'était le vrai risque, résolu en quatre jours une fois nommé.

Si vous ne pouvez pas le faire vous-même

Ma supervision de prestataire fait exactement cela : je note chaque sprint face aux critères écrits, je rends un verdict écrit mensuel de deux pages avec un go / no-go sur chaque version, et je n'ai aucun intérêt à ce que le prestataire garde le contrat. Pour savoir d'abord où en est un projet en cours, l'audit de risque projet donne une matrice de risques en dix jours ouvrés.