Vérifier avant de valider

Comment repérer les défauts d’une application générée et vérifier qu’une correction fonctionne ?

  • Lovable
  • Claude Code
  • Codex

1250 € par session, HTVA

En résumé

Cette demi-journée de 3 heures propose une découverte guidée des tests sur une application générée. Les participants traduisent des règles simples en vérifications, reproduisent des anomalies et contrôlent une correction. Ils repartent avec un cahier de tests renseigné et un bilan factuel, sans assimiler démonstration réussie et fiabilité complète.

Pourquoi cette formation ?

Une interface convaincante peut masquer une réservation impossible, une validation absente ou une information perdue après actualisation. Vérifier uniquement le parcours idéal laisse ces défauts invisibles et conduit à accepter trop vite le résultat généré. Un retour comme « cela ne marche pas » aide peu à corriger. Décrire les étapes, le résultat attendu et le résultat observé permet de demander une modification ciblée, puis de vérifier humainement son effet. Cas fil rouge : L’organisation fictive « Avelune Prêts » dispose d’une application générée de réservation de matériel. Une réservation doit comporter un nom fictif, un équipement disponible et une date de retour postérieure au départ. Les participants vérifient ces règles sur une version pédagogique comportant des défauts préparés. Transfert au travail : Réutiliser le cahier sur un parcours simple d’une application autorisée, avec des données anonymisées. Faire relire les anomalies par le responsable technique avant toute correction et conserver les résultats avant/après.

Les objectifs de cette formation

  • Distinguer un comportement attendu d’une anomalie observable.
  • Rédiger six cas de test couvrant parcours normal, erreur et limite.
  • Exécuter des vérifications manuelles et consigner leurs résultats.
  • Décrire une anomalie reproductible avec sa gravité.
  • Comparer les résultats avant et après une correction guidée.

Pour qui et avec quels prérequis ?

Rôles et tâches concernés

  • Débutants qui découvrent les applications générées et souhaitent apprendre à les vérifier.
  • Porteurs de projets non techniques amenés à commenter une première version d’application.

Compétences préalables

  • Aucun prérequis IA ni connaissance de programmation.
  • Savoir utiliser un navigateur et remplir un formulaire.

Ce que vous travaillerez

  1. Observer sans confondre apparence et conformité

    Objectif : Identifier ce que les règles de réservation permettent de vérifier. Résultat attendu, résultat observé, défaut fonctionnel et limite d’une démonstration ; distinction entre tests manuels et automatisés.

  2. Construire des cas révélateurs

    Objectif : Préparer six vérifications complémentaires. Parcours nominal, champ vide, équipement indisponible, dates incohérentes et valeur limite ; importance d’un état initial connu.

  3. Exécuter et documenter les écarts

    Objectif : Produire une preuve exploitable plutôt qu’une impression. Reproductibilité, capture sans information sensible, gravité selon l’impact ; distinction entre échec et impossibilité d’exécuter.

  4. Contrôler une correction proposée

    Objectif : Vérifier une modification sans présumer de sa fiabilité. Génération et modification de code sur instructions avec Lovable, Claude Code ou Codex ; revue humaine, protection des secrets et non-régression. Consulter la documentation officielle pour les modalités propres à chaque outil.

Ce que vous emportez

  • Cahier de six cas de test renseigné.
  • Fiche d’anomalie reproductible et priorisée.
  • Consigne de correction ciblée avec points de revue humaine.
  • Bilan avant/après précisant réussites, échecs et tests non exécutés.

Méthode et évaluation

  • Apports courts suivis de pratique immédiate sur le cas fil rouge.
  • Travail individuel puis en binômes, avec relecture croisée des productions.
  • Mise en commun guidée : ce qui fonctionne, ce qui doit être corrigé, ce qui reste une décision humaine.
  • Préparation : Prévoir un accès à l’application pédagogique isolée et à un outil autorisé par l’organisation parmi Lovable, Claude Code ou Codex. Préparer des réservations fictives, une version initiale conservée et les règles attendues ; exclure données personnelles, identifiants réels et secrets.

Critères observables : Chaque test précise données, étapes et résultat attendu. ; Les six cas couvrent au moins un parcours valide, une saisie invalide et une valeur limite. ; L’anomalie peut être reproduite à partir de la fiche seule. ; La correction est suivie du même test et de deux vérifications de non-régression. ; Le bilan distingue explicitement tests réussis, échoués et non exécutés..

Questions fréquentes

Faut-il savoir lire du code ?

Non. Les exercices portent sur les comportements visibles ; la revue technique de la correction est accompagnée.

Utilise-t-on les trois outils ?

Non. Un seul outil autorisé suffit ; les principes de vérification restent communs.

Peut-on tester une application interne ?

La séance utilise le cas fictif. Tout transfert exige autorisation, environnement adapté et données anonymisées.

Des tests réussis autorisent-ils une mise en production ?

Non. Ce contrôle introductif ne remplace ni revue de sécurité ni validation technique complète.

Dernière mise à jour :