Votre prestataire avance‑t‑il vraiment ? Comment le savoir sans lire de code

Chaque livraison a une date et quelque chose à essayer : un écran, un bouton, un export. Vous savez ce qui est sorti mardi, et vous pouvez cliquer dessus.

Signal d'alerte : « C'est fait à 80 % », trois semaines de suite. Un pourcentage ne se teste pas. Et les derniers 20 % sont souvent les plus longs.

Chaque demande a sa ligne et son statut : à faire, en cours, livrée, validée. Vous l'ouvrez quand vous voulez, sans demander à personne.

Signal d'alerte : La liste vit dans la tête du prestataire, ou dans un fil d'emails. Pour savoir où on en est, il faut écrire, puis attendre.

On l'appelle recette, ou préversion. C'est une copie du produit, à une adresse à part, où chaque livraison arrive avant la mise en ligne. Vous y cliquez comme vos clients.

Signal d'alerte : Vous ne voyez rien avant la mise en ligne. Ou on vous envoie des captures d'écran au lieu d'un lien.

Qui utilise cette fonction ? Que se passe-t-il si le champ est vide ? Quel cas passe en premier ? Un bon prestataire pose ces questions avant de coder, pas après.

Signal d'alerte : Jamais une question. Il livre ce qui est écrit, pas ce que vous vouliez. Et vous le découvrez à la fin.

Le produit en ligne change souvent, par petits morceaux. Chaque morceau est petit, donc facile à vérifier, et facile à défaire s'il pose problème.

Signal d'alerte : Tout sortira d'un coup, à la fin. Un « big bang » final concentre les risques sur un seul jour, et vous prive de retours pendant des mois.

Une liste, un endroit, un ordre. C'est vous qui décidez ce qui passe en premier. Le prestataire propose, il ne range pas à votre place. Deux listes, la vôtre et la sienne, c'est déjà un écart.

Un besoin, une demande. Qui a le problème, ce qu'il essaie de faire, comment vérifier que c'est fait. Une demande claire se livre plus vite, et se valide sans débat.

Toutes les deux semaines, par exemple. Trente minutes. Ce qui est sorti, ce qui bloque, ce qui passe en tête. Pas un point d'état : un point de décision.

Vous testez. Puis vous validez, ou vous demandez un ajustement. Par écrit. Une livraison non validée n'est pas finie, et la suivante ne devrait pas s'empiler dessus.

Le dépôt de code, l'hébergement, le nom de domaine, les comptes tiers. Chacun passe à votre nom, avec vous comme administrateur. Commencez par là, avant toute discussion sur la suite : sans les accès, vous ne décidez rien.

Tout l'historique du dépôt, pas une archive envoyée par email. La documentation, même partielle. Puis relisez votre contrat : que dit-il de la propriété du code ? Sans cession écrite des droits, le code peut rester au prestataire.

Une équipe extérieure lit le code et vous dit ce qui tient, ce qui est fragile, ce qui présente un risque. Elle n'a rien à défendre. Son avis pèse plus que celui du prestataire sortant.

En général, on part de l'existant. Un code mal suivi n'est pas forcément un mauvais code. On sécurise, on comprend, puis on fait évoluer par petites demandes. La réécriture se décide avec des faits, partie par partie, si elle se décide.