Une démo montre qu’une idée peut fonctionner sur un parcours donné. Elle vous aide à expliquer le produit et à voir si le parcours a du sens. Avant que des clients en dépendent, il faut aussi comprendre ce qui se passe avec d’autres utilisateurs, de vraies données et des interruptions.
Cela vaut quelle que soit l’origine du prototype : un modèle, un outil d’IA, une équipe interne ou un ancien développeur. J’évaluerais ce qui est déjà utile, je repérerais les manques et je planifierais le travail autour des risques qui comptent pour ce produit.
Notez ce qui est réel et ce qui est simulé
Un prototype peut afficher des données d’exemple, simuler un paiement ou supposer que chaque requête réussit. Listez ces hypothèses. Un écran qui affiche une réservation réussie peut encore avoir besoin de règles de disponibilité, d’une connexion au paiement et d’un enregistrement fiable de la réservation.
Gardez les parties utiles de la démo. L’audit devrait expliquer ce qui peut rester, ce qui doit changer et ce qui n’a pas encore été vérifié. On ne peut pas faire le tri en regardant seulement les écrans.
Vérifiez ce que chaque personne a le droit de faire
Décrivez les rôles de votre produit et ce que chaque rôle peut voir ou modifier. Masquer un bouton d’administration dans l’interface n’est qu’une partie du travail ; les actions et données protégées doivent aussi être contrôlées côté serveur.
Dans un espace client, par exemple, vérifiez qu’un client ne peut pas récupérer les données d’un autre et que retirer l’accès d’un membre de l’équipe a bien l’effet voulu. L’OWASP Application Security Verification Standard est une référence pour structurer la vérification de sécurité d’une application. Les contrôles retenus pour votre produit devraient refléter ses données et ses risques.
Passez en revue les pannes et les actions répétées
Un client peut perdre sa connexion, recharger une page, envoyer deux fois un formulaire ou revenir après l’expiration d’une intégration. Il nous faut un résultat convenu pour ces situations, surtout quand de l’argent, du stock ou des données importantes sont en jeu.
Que doit-il se passer si un paiement est en attente ou échoue ?
Peut-on relancer une requête sans risque de créer un doublon ?
Que verra l’utilisateur si un envoi de fichier ou une notification échoue ?
Comment l’équipe repère-t-elle et règle-t-elle une opération incomplète ?
Dans l’exemple de réservation, des clics répétés ne doivent pas créer plusieurs réservations pour un seul achat voulu. La mise en œuvre adaptée dépend du prestataire de paiement et des règles de réservation ; ce comportement fait partie du périmètre et des tests.
Utilisez des données représentatives et des parcours réalistes
Testez les noms longs, les listes vides, les historiques plus fournis, les champs manquants et les appareils que les gens utiliseront. Un tableau de bord avec cinq lignes d’exemple ne montre pas comment on retrouve un enregistrement parmi des milliers. Utilisez des données de test adaptées plutôt que de copier des informations clients privées dans un aperçu non protégé.
Si des données existantes doivent être migrées dans le produit, prévoyez la correspondance des champs, un import d’essai et les vérifications. Décidez comment traiter les doublons et les enregistrements incomplets, et ce que deviennent les changements faits pendant la migration.
Rendez explicite le plan de mise en ligne et de reprise
Sachez à qui appartiennent les comptes d’hébergement et de services, quelle configuration est nécessaire et comment la version arrive dans le bon environnement. Avant qu’un changement passe en production, convenez des vérifications et de la façon de revenir en arrière s’il pose problème.
Revenir en arrière peut demander plus que restaurer une ancienne version du code. Un changement dans les données stockées a besoin de sa propre approche. L’équipe devrait savoir quelles sauvegardes existent, comment les restaurer et quelles vérifications confirment que le produit fonctionne ensuite.
Lancez pour apprendre, avec un responsable du service
Une mise en ligne contrôlée auprès d’un groupe adapté peut révéler des problèmes avant d’ouvrir l’accès plus largement. Décidez comment les retours et les erreurs seront collectés, qui y répond et ce qui vous ferait suspendre ou annuler le déploiement. Leguide de GOV.UK sur la phase bêta décrit comment utiliser une mise en ligne limitée pour apprendre et améliorer avant d’ouvrir un service plus largement.
Le parcours principal a été vérifié par : …
Les droits et les principaux cas d’échec ont été vérifiés par : …
Les limites restantes sont : …
Les étapes de mise en ligne et de reprise sont documentées ici : …
La personne qui gère les retours et les incidents est : …
Nous élargirons l’accès quand : …
Ce sont des questions pour planifier, pas une certification de sécurité. Le niveau de vérification doit être proportionné au produit et aux conséquences d’une panne. Si vous avez un prototype,dites-moi ce qui fonctionne déjà et ce que vous voulez lancer. Nous pourrons voir ensemble les prochaines étapes.