De l’idée à la mise en ligne : cinq points à vérifier

1. Périmètre : que doit faire la première version ?

Prenons un calculateur de devis fictif, destiné à estimer ses propres coûts. On saisit quantité, prix unitaire et livraison ; il affiche le total. La première version n’enregistre aucun client et n’encaisse aucun paiement.

Écrivez ce périmètre dans le besoin et ajoutez un résultat de référence : quantité 10, prix unitaire 12 et livraison 8 doivent donner 10 × 12 + 8 = 128. Vous et l’IA disposez ainsi du même critère pour vérifier le calcul.

Si vous voulez ensuite des comptes, des commandes ou un paiement, listez séparément les problèmes à résoudre et répartissez-les entre versions selon votre temps et vos compétences.

2. Parcours : peut-on aller du début au résultat ?

Reprenez le parcours d’une personne qui découvre l’outil : ouvrir la page, remplir les champs, calculer, trouver le résultat, modifier une entrée et recalculer. Vérifiez l’emplacement des unités, montants et indications.

Faites la même chose sur téléphone. Le clavier masque-t-il le bouton ? Faut-il chercher le résultat en faisant défiler la page ? Gardez étapes et entrées pour rejouer ce parcours après les modifications.

3. Erreurs : sait-on comment continuer ?

Essayez une quantité vide, un prix négatif et une quantité décimale. Le message doit indiquer ce qu’il faut corriger et permettre de continuer une fois l’entrée rectifiée.

Si le projet appelle un service externe, essayez aussi échec et délai dépassé : l’attente se poursuit-elle sans fin, peut-on réessayer, des enregistrements risquent-ils d’être créés en double ? Complétez selon les fonctions réelles. Un calculateur statique n’a pas besoin d’un serveur sans utilité pour son fonctionnement.

4. Données : qu’enregistre-t-on et qui peut y accéder ?

Déterminez si les entrées restent dans le navigateur ou sont envoyées à un serveur ou à un service tiers. Si vous conservez des données métier, définissez qui peut les consulter et les modifier, puis essayez avec plusieurs comptes.

Masquer du contenu dans la page ne suffit pas : le serveur doit aussi vérifier les droits de lecture. L’exemple fictif de fiche client permet de préparer deux essais distincts : consulter ses données et tenter de consulter celles d’un autre compte.

5. Publication : le parcours fonctionne-t-il à l’adresse finale ?

Choisissez un hébergement adapté et notez les étapes de construction, de publication et de démarrage. À l’adresse finale, vérifiez HTTPS, affichage mobile, liens principaux et actualisation, puis rejouez l’exemple de calcul. S’il y a un serveur, contrôlez aussi configuration de production, lecture et écriture des données et accès aux erreurs.

Avant de publier, gardez une version utilisable et sachez la restaurer. Si les changements touchent aux données métier, prévoyez une sauvegarde adaptée et vérifiez ce que deviennent les données quand le code revient à une version précédente.

Conserver les repères pour la suite

Gardez le besoin, la version utilisable, les entrées de test, le mode d’emploi et les problèmes encore ouverts. Après publication, observez où les personnes qui vont utiliser l’outil s’arrêtent et corrigez selon l’impact. Ajoutez des exemples à chaque nouvelle fonction.

La liste avant mise en ligne est téléchargeable. Si vous êtes au début, utilisez le modèle de cadrage pour préciser d’abord objectif et périmètre.

Questions fréquentes

À lire ensuite

• Créer son premier site — Commencer par un besoin sur une page
• Vérifier avant la mise en ligne — Choisir les points adaptés aux fonctions
• Chercher la cause d’un problème — Garder les symptômes et avancer par étapes