Recette d’une application web : le guide pour dirigeants

La recette d’une application web consiste à vérifier, avant sa validation, que le logiciel livré permet réellement d’effectuer les opérations prévues. Pour un dirigeant, l’objectif n’est pas de contrôler le code : c’est de s’assurer que les équipes pourront travailler, que les données seront fiables et que les situations à risque ont été testées.

Cette validation doit être préparée avant de choisir un prestataire. Vous pourrez ainsi comparer des offres qui incluent les mêmes responsabilités, les mêmes preuves et les mêmes conditions de livraison. Voici une méthode pour définir les tests utiles, organiser vos équipes et décider de la mise en service sans vous transformer en expert technique.

Qu’est-ce que la recette d’une application web ?

La recette d’une application web est une vérification structurée de la livraison par rapport aux exigences convenues. Elle repose sur des scénarios métier, des résultats attendus et une décision documentée : accepter, accepter avec des réserves ou demander des corrections.

Pensez à la réception d’un atelier : constater que les machines sont présentes ne suffit pas. Il faut vérifier qu’elles produisent correctement, que les opérateurs peuvent les utiliser et que les dispositifs de sécurité fonctionnent.

Pour une application, distinguez trois activités :

• La démonstration : le prestataire présente le fonctionnement du produit.
• Les tests techniques : l’équipe de développement vérifie les composants et leurs échanges.
• La recette métier : vos utilisateurs exécutent les opérations attendues avec des données représentatives.

Demandez également une validation de la préparation à l’exploitation : surveillance, assistance, sauvegardes et procédure de retour en arrière. Une application peut satisfaire les besoins métier sans être prête à fonctionner dans de bonnes conditions.

Que faut-il prévoir avant de signer avec un prestataire ?

Avant de signer, définissez les éléments qui permettront de reconnaître une livraison acceptable. Faites préciser qui prépare les tests, qui les exécute, comment les anomalies sont traitées et qui prend la décision finale.

Ces éléments constituent une partie du cadrage d’un projet d’application web, au même titre que les fonctionnalités ou les connexions aux outils existants.

Transformer les besoins en critères vérifiables

« La gestion des commandes doit être simple » exprime une intention, mais ne permet pas de trancher un désaccord. Préférez un critère observable : « Un gestionnaire peut créer une commande, appliquer le tarif du client, la faire approuver et retrouver son historique. »

Ajoutez les limites importantes : qui peut approuver, quelles informations sont obligatoires, ce qui se passe après une annulation et quelles données partent vers la facturation.

Chaque fonctionnalité importante doit avoir une preuve de fonctionnement attendue. Cette preuve peut être un écran, un document généré, un calcul vérifié ou une opération retrouvée dans un autre logiciel.

Clarifier la procédure de validation

Demandez que les documents du projet précisent :

• le périmètre exact de la livraison à valider ;
• les conditions nécessaires pour commencer les tests ;
• la disponibilité attendue de vos collaborateurs ;
• les catégories d’anomalies et leur traitement ;
• la procédure de vérification après correction ;
• les modalités de validation et de suivi des réserves.

Faites expliciter les éventuels mécanismes d’acceptation en l’absence de réponse. Leur portée dépend du contrat : pour un engagement sensible, faites examiner les dispositions par un conseil compétent plutôt que de vous fier à une formulation générique.

Construire un cahier de recette centré sur le métier

Un cahier de recette est un document qui décrit les opérations à tester et les résultats à obtenir. Un tableur partagé peut suffire si chaque scénario possède un identifiant, un responsable et un statut.

Pour un logiciel métier sur mesure, partez des parcours complets, pas seulement de la liste des écrans. Une fiche client correcte ne prouve pas que la commande, la livraison et la facturation s’enchaînent correctement.

Exemple fictif : valider une commande avec remise

Voici un scénario pédagogique pour une PME de négoce. Il ne décrit pas un projet client de Novane.

Pour chaque scénario, indiquez aussi la version testée, la date, le résultat observé et l’éventuelle anomalie. Évitez le statut « presque conforme » : distinguez réussite, échec, test bloqué et test non exécuté.

Ajouter les exceptions qui changent la décision

Après le parcours normal, testez les situations qui pourraient compromettre l’activité :

• une information obligatoire manque ;
• l’utilisateur clique deux fois sur la confirmation ;
• un produit devient indisponible pendant la commande ;
• la connexion avec un autre logiciel échoue ;
• deux personnes modifient le même dossier ;
• une opération est annulée après transmission.

Complétez ces tests prévus par une exploration encadrée. Le Service Manual britannique décrit les tests exploratoires comme une utilisation du système sans scénario prédéterminé, avec un objectif et des observations documentées. Confiez, par exemple, à un utilisateur la mission de traiter un dossier inhabituel et de noter ses difficultés. (gov.uk)

Quels contrôles ne faut-il pas oublier ?

La recette d’une application web doit couvrir les parcours métier, mais aussi les accès, les échanges de données et les conditions d’utilisation. Priorisez les contrôles selon les conséquences d’un échec, pas selon la visibilité de la fonctionnalité.

Les droits d’accès

La CNIL recommande de limiter les accès aux données nécessaires aux missions de chaque utilisateur et de retirer les permissions devenues injustifiées. Cette logique, présentée dans sa fiche sur la gestion des habilitations, doit se traduire en scénarios de recette. (cnil.fr)

Testez chaque profil avec un compte distinct. Vérifiez non seulement ce qu’un commercial peut consulter, mais aussi ce qu’il ne doit pas obtenir : dossiers d’une autre équipe, export global ou fonction d’administration.

Pour un SaaS, c’est-à-dire un logiciel accessible en ligne sous forme de service, demandez notamment les preuves de séparation entre les données des entreprises clientes. Ne considérez pas la disparition d’un bouton comme une preuve suffisante de protection.

Les données et les connexions aux autres outils

Une API est une interface qui permet à deux logiciels d’échanger des informations. Lorsque votre application utilise une API, faites vérifier l’ensemble du trajet : envoi, réception, traitement et gestion des erreurs.

Pour une connexion à un ERP, le logiciel qui centralise la gestion de l’entreprise, contrôlez les montants, les références et les statuts obtenus. Prévoyez une panne simulée : qui est averti, où l’erreur apparaît-elle et comment reprendre l’opération sans créer de doublon ?

Si vous reprenez des données anciennes, définissez les rapprochements attendus : nombre de dossiers, totaux financiers pertinents et vérification d’échantillons choisis par les métiers. Un import terminé n’est pas, à lui seul, une validation de son contenu.

Les appareils, l’accessibilité et les performances

Précisez les navigateurs et appareils à prendre en charge. Pour une application terrain, incluez les conditions réelles : téléphone, réseau irrégulier et interruption d’une saisie.

Demandez des vérifications d’usage au clavier, de compréhension des erreurs et de lisibilité. Les obligations d’accessibilité applicables doivent être examinées selon votre activité ; la recette métier ne remplace pas une évaluation spécialisée.

Pour les performances, faites définir les conditions du test : volume de données, utilisateurs simultanés et opérations mesurées. « L’application est rapide » n’est pas un engagement vérifiable.

La sécurité et la restauration

Le référentiel ASVS de l’OWASP fournit une base pour vérifier les contrôles de sécurité d’une application web. Demandez au prestataire quelles exigences pertinentes ont été retenues, quels tests ont été réalisés et quels problèmes restent ouverts. Vos essais métier ne remplacent pas ces vérifications techniques. (owasp.org)

Pour les sauvegardes, exigez davantage qu’une capture indiquant « sauvegarde réussie ». La CNIL recommande de tester leur intégrité et la capacité à restaurer les données. Demandez une preuve de restauration et comparez les conditions obtenues aux besoins de votre activité. (cnil.fr)

Qui doit participer à la recette ?

La recette doit être pilotée par un responsable côté entreprise, avec des utilisateurs représentatifs et un interlocuteur technique côté prestataire. Le dirigeant arbitre les risques et les priorités, sans nécessairement exécuter tous les tests.

Réservez les créneaux dans les agendas avant la livraison. Si vos utilisateurs testent uniquement lorsqu’ils trouvent du temps, vous ne disposez pas d’une capacité de validation planifiable.

Incluez un utilisateur qui n’a pas participé à la conception. Demandez-lui d’effectuer une opération avec les seules consignes qui seront disponibles au lancement : vous vérifierez aussi la qualité de l’accompagnement.

Combien coûte la recette d’une application web ?

Le coût de la recette dépend du nombre de parcours, des profils d’accès, des connexions et du niveau de risque. Demandez un chiffrage détaillé plutôt qu’un pourcentage automatique du budget de développement.

Sans périmètre défini, une fourchette en euros serait peu utile. Faites distinguer les postes suivants dans les propositions :

• Préparation : scénarios, données, comptes et environnement de test.
• Exécution : temps des utilisateurs et accompagnement éventuel.
• Contrôles spécialisés : sécurité, performances ou accessibilité selon le projet.
• Corrections et nouvelles vérifications : modalités de prise en charge à préciser.
• Préparation du lancement : documentation, assistance et procédure de repli.

Votre temps interne est également une dépense du projet. Pour l’estimer, listez les scénarios attribués à chaque collaborateur, prévoyez la documentation des résultats et ajoutez une nouvelle vérification après les corrections.

Pour comparer les devis, demandez ce qui est inclus, ce qui est optionnel et ce qui déclenche une facturation supplémentaire. Distinguez une anomalie par rapport au besoin convenu d’une demande nouvelle : changer une règle métier après développement n’est pas la même chose que corriger son application incorrecte.

Organiser la validation en étapes maîtrisables

La durée de la recette doit être estimée à partir du travail réel et de la disponibilité des personnes. Planifiez des validations intermédiaires pour ne pas découvrir tous les écarts au moment de la livraison finale.

1. Fixer le périmètre à tester. Identifiez la livraison et les fonctionnalités concernées.
2. Préparer les conditions de test. Vérifiez les comptes, les données, les appareils et les connexions.
3. Recevoir les preuves du prestataire. Examinez les tests réalisés et les limites connues.
4. Exécuter les scénarios métier. Commencez par les opérations dont l’échec compromettrait l’activité.
5. Qualifier les anomalies. Documentez leur impact et convenez du traitement.
6. Vérifier les corrections. Rejouez le scénario concerné et les parcours associés.
7. Documenter la décision. Listez les réserves, leurs responsables et les conditions du lancement.

Un environnement de test est une installation séparée utilisée pour les vérifications. La CNIL recommande, dans sa fiche sur les développements informatiques, des données fictives ou anonymisées pour le développement et les tests, et encadre les situations nécessitant des données réelles. Privilégiez un jeu représentatif sans exposer inutilement des informations personnelles. (cnil.fr)

Comment décider si l’application peut être mise en service ?

La décision doit dépendre des risques résiduels et des critères convenus. Nous recommandons de ne pas lancer une application avec une anomalie connue compromettant la confidentialité, l’intégrité des données ou une opération métier indispensable.

Convenez à l’avance d’une classification simple :

Un procès-verbal de recette est le document qui consigne le résultat de la validation. Prévoyez la version concernée, les tests effectués, les contrôles non réalisés, les anomalies ouvertes et la décision prise. Adaptez son contenu aux dispositions de votre contrat.

Séparez la validation de la livraison et l’autorisation de mise en service. Même si les parcours fonctionnent, vous pouvez attendre la formation, la disponibilité du support ou la fin d’une période sensible pour lancer.

Les erreurs qui rendent la recette peu fiable

• Tester uniquement avec un compte administrateur. Les droits des utilisateurs ordinaires restent alors non vérifiés.
• Valider seulement les écrans. Suivez aussi les documents, les calculs et les échanges entre logiciels.
• Changer le besoin pendant la campagne. Séparez corrections et nouvelles demandes pour conserver un périmètre lisible.
• Signaler « ça ne marche pas ». Décrivez les étapes, le résultat attendu, le résultat obtenu et les conditions du test.
• Accepter une correction sans la rejouer. Demandez une nouvelle vérification, y compris des parcours susceptibles d’être affectés.
• Confondre lancement pilote et absence de validation. Un pilote doit lui aussi avoir des critères de sécurité, de réussite et d’arrêt.

Questions fréquentes

Faut-il un logiciel spécialisé pour suivre la recette ?

Pas nécessairement. Un tableur et un espace de partage peuvent convenir à un projet limité. Choisissez un outil spécialisé si vous devez relier beaucoup de tests, de versions et d’anomalies, ou coordonner plusieurs équipes.

Peut-on faire intervenir un tiers indépendant ?

Oui. Un tiers peut examiner les critères, exécuter des contrôles spécialisés ou aider à qualifier un désaccord. Précisez sa mission, ses accès et les livrables attendus avant son intervention.

Comment tester une fonctionnalité d’intelligence artificielle ?

Constituez un ensemble d’exemples avec les réponses acceptables, les erreurs interdites et les situations où l’outil doit refuser ou demander une validation humaine. Pour une fonctionnalité générative, testez plusieurs exécutions et ne jugez pas la qualité sur une seule démonstration.

Faut-il refaire toute la recette après chaque évolution ?

Adaptez les contrôles au changement. Testez la fonction modifiée, ses dépendances et un ensemble stable de parcours critiques. Demandez au prestataire de justifier ce périmètre de vérification avant la livraison.

Préparer la livraison avant de choisir votre prestataire

Pour préparer la recette d’une application web, commencez par écrire vos parcours indispensables, vos erreurs inacceptables et les personnes capables de valider les résultats. Vous disposerez d’une base concrète pour discuter des offres et de la livraison.

Si ces critères restent difficiles à définir, la séance de consulting IT offerte de Novane peut servir à clarifier le périmètre, les risques et les conditions de validation de votre projet avant de vous engager.