Beaucoup de dirigeants qui lancent leur première App ont l'état d'esprit « on confie ça à un prestataire et on attend la mise en ligne ». Le jour de la recette, ils découvrent que la connexion est lente, que les messages n'arrivent pas, qu'il faut une demi-journée pour modifier une donnée dans le back-office, et les deux parties commencent à se renvoyer la balle : l'un dit que le besoin n'était pas clairement défini, l'autre dit que cela implique un supplément. Les reprises s'étalent sur un ou deux mois, et le budget comme la fenêtre de lancement disparaissent avec.
Le problème n'est généralement pas technique : c'est la recette elle-même qui n'a pas été pensée comme une partie du projet. Voici, dans l'ordre, les points à clarifier pour éviter la majorité des reprises.
Définir noir sur blanc « ce qu'on vérifie » avant la recette
La recette ne commence pas une semaine avant la mise en ligne. Dès la signature du contrat ou le lancement du projet, il faut une liste de fonctionnalités vérifiable, avec un niveau de détail allant jusqu'à « quel bouton on clique, quel résultat apparaît ».
Par exemple, pour un projet de développement de mini-programme de réservation, la liste ne peut pas se contenter de « prise de rendez-vous possible » ; elle doit préciser : après avoir choisi une date, l'utilisateur ne peut pas sélectionner un créneau complet, il reçoit une notification après validation, et le commerçant voit le statut de la commande dans son back-office. Plus c'est précis, moins on se dispute au moment de la recette.
Piège à éviter : ne pas utiliser « comme telle App » comme cahier des charges. Ce que l'autre comprend et ce que vous comprenez ne seront presque jamais identiques.
Vérifier par parcours, pas seulement en cliquant sur l'interface
Une belle interface ne signifie pas qu'elle est utilisable. Je recommande de suivre ce fil conducteur :
1. Parcours principal de bout en bout : inscription, connexion, activité cœur, paiement, déconnexion, à tester sur un vrai téléphone et un vrai réseau.
2. Cas anormaux : coupure réseau, réseau faible, soumissions répétées, timeouts, permissions refusées ; vérifier que les messages sont clairs et que les données ne sont pas corrompues.
3. Back-office : dans beaucoup de projets de développement d'App, le front fonctionne, mais le système d'administration ne permet ni de modifier les données ni de consulter les logs, ce qui bloque directement l'exploitation.
4. Multi-modèles : couvrir au minimum les modèles et versions de système majoritaires, ne pas se contenter d'une démonstration sur un seul appareil de test.
Piège à éviter : pendant la recette, ne pas laisser le prestataire vous faire une démonstration avec un compte de test interne ; créez vous-même un nouveau compte et faites le parcours complet.
Des livrables incomplets équivalent à une absence de livraison
Le code, la base de données, les comptes serveur, les comptes de services tiers (push, paiement, cartographie), la documentation d'API et les instructions de déploiement doivent être listés clairement dans le contrat.
Cas fréquent dans la réalité : le site web d'entreprise et l'App ont été confiés à deux prestataires différents, et personne ne sait plus qui détient les comptes ; lorsqu'on veut changer d'équipe pour la maintenance, on découvre qu'on n'a pas le code et qu'on ne peut pas se connecter au serveur.
Piège à éviter : prévoir une section distincte « liste des livrables » dans le procès-verbal de recette, cocher chaque élément, et ne pas signer s'il en manque un. Héberger le code source dans un dépôt à votre nom, avec des droits que vous maîtrisez.
Tester la sécurité et la performance séparément
Les tests fonctionnels ordinaires ne révèlent pas les problèmes de sécurité. Faites au minimum trois choses :
- essayer d'accéder aux données d'un autre utilisateur avec un compte ordinaire pour détecter les défauts d'autorisation ;
- vérifier si les API renvoient des champs qu'elles ne devraient pas (numéro de téléphone, pièce d'identité, etc.) ;
- mesurer le temps de chargement des pages clés en réseau faible.
Si l'activité implique des transactions ou des données personnelles, je recommande de réaliser un test de sécurité du site web dédié ou des tests de sécurité au niveau des API, afin d'exposer les problèmes avant la mise en ligne.
Piège à éviter : ne pas attendre que les utilisateurs ou un scan de sécurité découvrent les problèmes après la mise en ligne ; le coût de correction est alors plusieurs fois supérieur à celui d'avant mise en ligne.
Lier le rythme de recette au solde final
Découpez la recette en deux ou trois tours : premier tour avec une liste de problèmes, deuxième tour de contre-vérification, troisième tour de régression avant mise en ligne. Chaque tour fait l'objet d'un compte rendu écrit : qui a signalé, qui a corrigé, quand est-ce terminé.
Le solde final est lié au résultat de la recette ; conservez une partie à payer après une période de fonctionnement stable en production. Ce n'est pas un manque de confiance, c'est ce qui motive les deux parties à solder les problèmes.
Piège à éviter : ne pas signaler les problèmes à l'oral. Un « c'est un peu lent ici » sur WeChat ne sera reconnu par personne un mois plus tard.
Dans quels cas faire appel à MIC Studio
Si vous refaites votre site web d'entreprise, développez un mini-programme de réservation, ou avez besoin d'un développement d'App avec back-office, et que vous ne voulez pas vous épuiser dans les allers-retours de recette, vous pouvez en parler avec MIC Studio.
Nous réalisons du développement de sites web d'entreprise, de mini-programmes et d'Apps, ainsi que du développement de scripts, des tests de sécurité de sites web et des tests d'ingénierie inverse. Nous sommes particulièrement adaptés à ces situations : le besoin n'est pas encore complètement formalisé et il faut quelqu'un pour vous aider à établir la liste des fonctionnalités et les critères de recette ; ou un système existant doit être repris en maintenance et nécessite d'abord un audit du code et de la sécurité.
Ce qui ne nous convient pas, disons-le clairement : si vous voulez seulement un site sur template, avec un budget très serré et une mise en ligne en une semaine, une solution standardisée sera plus rentable.
Trois recommandations concrètes
1. Rédiger la liste de recette dès le lancement du projet : fonctionnalités, cas anormaux, back-office, livrables, quatre blocs détaillés au niveau cochable, en annexe du contrat.
2. Créer soi-même un compte et parcourir tout le flux : sans démonstration, sans appareil de test, faire le parcours principal sur un vrai réseau avec de vraies données.
3. Échelonner le solde final : payer une partie à la validation de la recette, le solde après une période de fonctionnement stable en production, pour traiter le coût des reprises dès la phase de recette.