C'est normal de valider une livraison sans tests d'intégration API, fallait-il l'imposer au contrat ?

Je bosse sur ce type de projet depuis des années : l'agence essaie juste de vous refiler la partie la plus chiante, à savoir les tests de cas d'usage. Qu'un endpoint réponde en 200 ne prouve rien du tout. Si la banque valide le paiement mais que votre serveur tombe en timeout pile à ce moment-là, il se passe quoi ? On ne met jamais en prod une passerelle de paiement non testée.

Sur les paiements, le nerf de la guerre, c'est la gestion des webhooks. Si l'utilisateur ferme son navigateur ou perd sa connexion, est-ce que le système traite la notification asynchrone en arrière-plan ? Comment réagit l'API en cas de remboursement ou d'annulation partielle ? Ils sont tenus de faire ces tests en sandbox avec des requêtes mockées et de vous fournir les logs.

Bloquez le solde tout de suite. Envoyez un mail disant : « Conformément à nos critères de recette, aucun PV de livraison ne sera signé sans la documentation des 5 scénarios de base en sandbox (débit réussi, plafond dépassé abandon 3D Secure, timeout et remboursement auto) ». Vous allez voir ils vont vite changer de ton.

On a fait la même connerie il y a deux ans sur notre site d'excursions à 18.000 EUR. On a fait confiance à l'agence et on a mis en prod direct : dès la première semaine, 22 clients ont été prélevés sans que le calendrier ne réserve leur place. Résultat : 3.100 EUR de remboursements et site fermé pendant 10 jours. Les 3 jours de tests qu'on n'a pas exigés nous ont coûté deux semaines d'enfer.

Regardez bien votre contrat : y a-t-il une clause sur la recette ou la mise en service ? S'ils ont mis la formule standard du genre « réputé accepté sans contestation sous 14 jours après livraison », faites vite une notification écrite de refus avant la fin du délai.

À mon avis l'agence n'a même pas de dev capable d'écrire de vrais tests d'intégration. En général ils installent un plugin tout fait, collent deux clés API et pensent que le taf est fini. C'est pour ça qu'ils bottent en touche. Même en insistant, pas sûr qu'ils sachent pondre un cahier de recette propre.

Pour la réception, exigez ces 3 éléments : 1) Le tableau des résultats de tests passés en sandbox, 2) Les captures d'écran des messages d'erreur affichés au client en cas d'échec, 3) Le rapport de réconciliation entre les transactions de test sur le dashboard bancaire et la base de données du site. Sans ça, la livraison n'est pas recevable.

pas de panique mais ne lâchez rien. les devs ont horreur de tester parce que corriger les bugs découverts retarde la livraison. tenez bon sur le paiement, pas un centime des 4.000 EUR ne doit sortir sans le rapport de test.

J'ai été soulagé en lisant cette réponse, donc ce n'est pas seulement mon cas. bref si les critères d'acceptation ne sont pas écrits la date de fin du projet est ouverte à discussion.

Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Je vais résumer ce qui a été dit jusqu'ici. Le système continue de vivre après la livraison ; la maintenance est un poste à part.

Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même. C'est confirmé par l'expérience.

Vous avez raison, je suis aussi passé par là. Le système continue de vivre après la livraison ; la maintenance est un poste à part.

Mettre en place un processus de demande de changement n'ralentit pas le travail, il l'accélère. Voilà, désolé si je me suis étendu.

Exactement, et ce n'est pas si connu que ça. Le système continue de vivre après la livraison ; la maintenance est un poste à part.

Je suis aussi curieux de savoir si d'autres font autrement.

Je ne savais pas ça. Avant de décider, regardez quelles données vous avez en main.

Bien sûr, cela change si votre situation est différente.

C'est une bonne idée d'avoir ouvert ce sujet.

Pourriez-vous préciser un peu ? Le système continue de vivre après la livraison ; la maintenance est un poste à part.

Je le note au cas où.

Il y a un point que je ne comprends pas. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Je suis passé par là, laissez-moi vous raconter. genre l'erreur commise du côté de tests integration api est généralement réversible mais coûteuse.

Je le note au cas où.

Je suis intéressé.