Comment vérifier un site créé avec l'IA avant de le publier

Une IA peut créer en quelques minutes une page d'accueil ou un formulaire qui semble terminé. Cette vitesse est l'avantage du vibe coding, mais elle facilite aussi la confusion entre un bel aperçu et un produit prêt. Un site peut paraître impeccable et comporter des liens erronés, des données qui disparaissent, des erreurs sans explication ou une action serveur qui fait confiance à des valeurs modifiables.

Ce contrôle de publication prend pour exemple l'inscription à un atelier. La personne choisit une session, saisit son nom et son e-mail et reçoit une confirmation. Sept contrôles séparent le brouillon généré d'une version que vous pouvez publier de manière responsable. Chacun exige une preuve observable, pas la phrase « ça devrait marcher ».

1. Fixez le résultat et le périmètre avant de tester

Écrivez une phrase contenant le résultat obligatoire : « Sur mobile et sur ordinateur, une personne intéressée peut choisir un atelier disponible, envoyer des coordonnées valides et recevoir une confirmation non ambiguë ». Ajoutez ce qui ne fait pas partie de cette version, par exemple les paiements, le compte utilisateur ou la synchronisation d'agenda.

Cette limite empêche l'IA d'ajouter des fonctions pendant la revue et de casser ce qui marchait déjà. Un prompt bien délimité indique aussi la zone concernée, ce qui doit rester identique et les critères d'acceptation. Enregistrez l'état initial dans le contrôle de version ou comme aperçu nommé pour identifier exactement ce qui a été testé.

2. Parcourez le chemin principal dans un vrai navigateur

Ouvrez le site en visiteur, pas seulement en personne qui lit le code. Partez de l'entrée publique, allez jusqu'à l'inscription, choisissez une session, remplissez le formulaire et regardez le résultat. Répétez après un rechargement et sur un écran étroit. Les liens, le focus, l'attente et la confirmation font partie du parcours.

Playwright recommande de tester le comportement visible pour la personne. Localisez un bouton par son rôle et son nom accessible, et vérifiez le message de succès visible. Une classe CSS interne ne prouve pas que quelqu'un peut trouver ou comprendre l'action.

Le cas correct ne suffit pas. Testez au minimum un état vide, une entrée invalide et une panne technique :

• Aucune session : la page explique la situation et propose une étape utile.
• E-mail incorrect : le champ reçoit une explication compréhensible et garde le focus.
• Double clic ou réseau lent : l'inscription n'est pas enregistrée deux fois.
• Le serveur ne répond pas : les données ne disparaissent pas en silence et le succès n'est pas simulé.

3. Protégez les deux côtés du formulaire

Les types de champ HTML, required, des limites raisonnables et une réponse immédiate aident à corriger les erreurs. MDN rappelle que la validation côté client n'est pas une mesure de sécurité complète, car une requête peut contourner l'interface. Le serveur doit imposer séparément les mêmes limites métier.

Pour l'inscription, le serveur n'accepte que des identifiants de sessions réelles, limite la longueur des champs, normalise l'e-mail de façon consciente et rejette les données inattendues. Il confirme aussi qu'une place reste disponible. Une valeur cachée dans le formulaire n'est pas une autorisation.

Dessinez le parcours des données : ce qui sort du navigateur, où c'est stocké, qui peut le lire et quand c'est supprimé. Si l'IA ne peut pas tirer de réponse claire du code et de la configuration, un risque reste ouvert.

4. Vérifiez clavier, sémantique et messages

WCAG offre un standard partagé pour un contenu web plus accessible. Vous n'avez pas besoin de le mémoriser entièrement pour une petite publication, mais le parcours principal doit rester compréhensible et utilisable sans souris. Naviguez avec Tab, Maj+Tab, Entrée et Espace. Le focus ne doit ni disparaître ni rester derrière une boîte de dialogue.

Vérifiez les libellés visibles, l'ordre des titres, le contraste, les alternatives des images et les messages d'état. Zoomez à 200 pour cent et utilisez un écran étroit. Un audit automatique trouve beaucoup de problèmes de base, mais ne remplace ni le test clavier ni une courte revue avec un lecteur d'écran ou avec des personnes.

5. Inspectez les limites de sécurité

L'OWASP regroupe des risques web récurrents comme le contrôle d'accès défaillant, la mauvaise configuration, les failles de chaîne d'approvisionnement et l'injection. Transformez ces catégories en questions concrètes. Une personne peut-elle lire les inscriptions d'autrui ? Un secret se trouve-t-il dans le paquet livré au navigateur ? Le serveur fait-il confiance à un rôle envoyé par le formulaire ? Les paquets externes et les variables d'environnement sont-ils maîtrisés ?

Demandez à l'IA de signaler d'abord les preuves et les emplacements avant de modifier quoi que ce soit. Authentification, paiements, informations de santé ou autres données sensibles méritent une revue expérimentée. Le code généré n'est pas dangereux par définition, mais son aspect convaincant peut masquer des hypothèses non vérifiées.

6. Mesurez la performance sur les appareils visés

web.dev présente LCP, INP et CLS comme Core Web Vitals stables pour le chargement, la réactivité et la stabilité visuelle. Ce sont des signaux utiles, pas un bouton universel de validation. Mesurez la page réelle avec ses images, polices, scripts et services externes de production.

Testez au moins un téléphone représentatif, une connexion limitée et un navigateur de bureau utilisé par votre public. Observez l'image principale, les scripts bloquants, les contrôles lents et les sauts pendant le chargement. Fixez un petit budget, comme des tailles d'images maximales et aucune dépendance externe bloquante sans justification.

7. Préparez approbation, observation et retour arrière

Avant de publier, répondez à trois questions : qui approuve ? quels signaux montreront une panne ? comment récupère-t-on la version précédente ? Un aperçu contrôlé, comme celui de l'article sur ChatGPT Sites, sert à la dernière revue lorsque son public et les données du formulaire sont choisis en conscience.

Publiez une version précise et testée, pas un vague « état actuel ». Vérifiez ensuite l'URL publique, le parcours principal, les erreurs serveur et les envois réels. Le retour arrière n'est fiable que si la version cible, la personne responsable et la procédure sont connues.

Liste compacte pour publier

• Objectif, exclusions et version testée sont consignés.
• Cas correct, état vide, entrée invalide et panne serveur ont été testés dans le navigateur.
• Client et serveur valident ; permissions et parcours des données sont compréhensibles.
• Le parcours fonctionne au clavier, en zoom et sur un téléphone pertinent.
• Secrets, variables d'environnement, dépendances et points publics ont été revus.
• La performance a été mesurée avec des ressources réelles et les régressions critiques corrigées.
• Approbation, observation et retour arrière ont une personne responsable.

Ces contrôles ne cherchent pas à supprimer la vitesse du travail assisté par IA. Ils protègent son véritable avantage : passer rapidement d'une idée à un produit utile dont vous pouvez expliquer et assumer le comportement. Quand une preuve manque, transformez ce manque en tâche suivante bien délimitée. L'itération restera rapide sans faire de la publication un pari.