Comment tester votre appli créée avec l'IA quand vous n'avez jamais testé de logiciel
Un guide concret pour tester une appli créée avec l'IA quand vous n'avez aucune expérience en QA. Où cliquer, quoi casser exprès, et comment savoir quand c'est assez bon pour la partager.
Vous avez créé une appli avec l’IA. Elle marche sur le chemin heureux — vous tapez votre nom, cliquez sur le bouton, voyez l’écran de succès. Et maintenant ? Est-elle prête à être envoyée à vos trois bêta-testeurs ? À votre équipe ? À vos clients ?
Si vous n’avez pas de bagage logiciel, tester ressemble à l’une de ces choses que font les « vrais développeurs » — avec des frameworks, des assertions et des pipelines de CI. La bonne nouvelle : ce n’est pas ce qu’est réellement la plupart des tests. La plupart des tests, surtout quand vous livrez quelque chose de petit et de nouveau, c’est une personne qui clique partout avec intention. Ça, vous savez le faire. Cet article parle de le faire exprès, pour trouver les bugs avant vos utilisateurs.
Le but n’est pas de tester votre appli créée avec l’IA comme un pro. C’est de la tester comme un ami paranoïaque qui veut sincèrement qu’elle fonctionne.
L’astuce des deux listes
Avant de cliquer sur quoi que ce soit, asseyez-vous dix minutes devant un document vierge et écrivez deux listes.
Liste A — les chemins heureux. Quelles sont les trois ou quatre choses qu’un utilisateur est censé faire avec cette appli ? Pour un SaaS typique, ce pourrait être : s’inscrire, créer son premier projet, inviter un coéquipier, exporter un résultat. Pour une appli de type annuaire : rechercher, filtrer, cliquer sur une fiche, l’enregistrer. Trois ou quatre vrais parcours, en langage clair.
Liste B — les chemins malheureux. Et si l’utilisateur fait presque la bonne chose, mais pas tout à fait ? Tape son e-mail avec une faute de frappe. Appuie sur le bouton retour en plein parcours. Ouvre deux onglets et modifie la même chose dans les deux. Soumet un formulaire vide. Colle le contenu d’un document Word — mise en forme comprise — dans un champ texte. Ferme l’ordinateur portable et le rouvre dix minutes plus tard. Essaie d’inviter un coéquipier avec une adresse e-mail qui existe déjà dans le système.
La liste des chemins heureux, c’est ce pour quoi votre créateur d’applis avec IA a optimisé. C’est ce que l’IA a mentalement testé en écrivant le code. La liste des chemins malheureux, c’est là que vivent les bugs, parce que presque personne — ni l’IA, ni vous au moment de la rédiger — ne pensait à ces cas.
Quand vous testez pour de vrai, parcourez d’abord la liste A pour confirmer que les bases fonctionnent. Puis passez l’essentiel de votre temps sur la liste B. C’est là qu’est la valeur. C’est aussi là que vous découvrez ce que vous voulez vraiment que l’appli fasse quand les choses dérapent, ce qui force souvent une conversation de clarification avec le créateur d’applis avec IA (« quand le formulaire est à moitié rempli, doit-il prévenir ou enregistrer automatiquement ? »).
Trois choses à casser exprès
Une fois vos listes prêtes, voici trois catégories qui attrapent la majorité des vrais bugs dans les applis créées avec l’IA.
Les entrées vides et bizarres. Soumettez le formulaire sans rien remplir. Soumettez-le avec un seul champ rempli. Soumettez un nom de 500 caractères. Soumettez un nom avec des émojis. Collez une URL dans un champ qui attend un nom. Essayez le champ e-mail avec « test », avec « test@ », avec « test@example », avec l’adresse « a@b.co » — accepte-t-il les e-mails courts mais légitimes ? Les créateurs d’applis avec IA ajoutent souvent une validation, mais la validation peut se tromper dans les deux sens — trop stricte (rejette de vrais utilisateurs) ou trop laxiste (accepte n’importe quoi).
Aller en arrière et de travers. La plupart des applis marchent très bien si on les parcourt comme un groupe de touristes obéissant. Elles cassent dès que quelqu’un explore. Cliquez sur le bouton retour. Cliquez à nouveau sur suivant. Actualisez la page en plein parcours. Ouvrez la même page dans deux onglets et modifiez-la dans les deux. Déconnectez-vous et reconnectez-vous. Si vous avez un bouton « annuler », cliquez dessus trois fois de suite. Ce ne sont pas des cas particuliers. C’est ainsi que de vraies personnes utilisent un logiciel.
Les données après coup. Créez ce que votre appli crée. Un projet, une publication, un enregistrement, peu importe. Puis revenez le lendemain. Est-ce toujours là ? La mise en forme a-t-elle survécu ? Si vous le modifiez, la modification s’enregistre-t-elle ? Si vous le supprimez, est-il vraiment parti, ou revient-il quand vous actualisez ? Les créateurs d’applis avec IA réussissent souvent le parcours de « création » et oublient que tout ce que vous créez doit persister et rester modifiable plus tard.
À quoi ressemble « assez bon »
Vous ne testerez jamais votre appli créée avec l’IA jusqu’à la perfection. Le logiciel est trop emmêlé et votre temps est trop précieux. La question n’est pas « est-ce parfait » — c’est « est-ce assez bon pour le prochain groupe de gens devant qui je vais le mettre ».
Voici une hiérarchie grossière que vous pouvez emprunter.
Assez bon pour une démo : le chemin heureux fonctionne sans planter. Les boutons mènent là où ils devraient. Vous pouvez montrer un enregistrement d’écran sans rien couper.
Assez bon pour des utilisateurs bienveillants : les chemins malheureux ne perdent pas de données. Les formulaires vous disent ce qui ne va pas au lieu d’échouer en silence. Actualiser la page ne casse rien. Trois amis peuvent l’utiliser sans vous écrire pour de l’aide.
Assez bon pour des utilisateurs payants : l’appli gère des utilisateurs que vous n’avez jamais rencontrés. Leurs navigateurs, leurs données, leurs habitudes. Vous avez un moyen de voir quand quelque chose casse (un suivi des erreurs basique suffit — pas besoin d’un tableau de bord sophistiqué). Vous pouvez corriger et redéployer sans casser pour les gens qui l’utilisent déjà.
La plupart des créateurs livrent au niveau « utilisateurs bienveillants » puis montent en gamme à mesure que les retours arrivent. C’est la bonne approche. L’erreur, c’est d’essayer de sauter de « assez bon pour une démo » directement à « assez bon pour des utilisateurs payants » sans l’étape intermédiaire. Les utilisateurs bienveillants trouvent les choses que de vrais utilisateurs trouveraient — mais ils ne s’en agacent pas. Servez-vous de cet écart.
Quand demander à l’IA de tester pour vous
Votre créateur d’applis avec IA peut aider à tester, mais vous devez être précis sur ce que vous voulez. « Ajoute des tests » est une mauvaise instruction. Il générera du code qui ressemble à des tests et qui passe probablement, sans vraiment vérifier ce qui vous tient à cœur. La plupart de ces tests générés automatiquement confirment que 1+1 fait toujours 2.
Une meilleure instruction : « Je viens d’essayer de soumettre le formulaire d’inscription avec un champ e-mail vide et ça a planté. Trouve où c’est géré et ajoute une vérification qui affiche une erreur claire à la place. » Bug précis, correction précise, résultat précis. L’IA est douée pour ça. Elle est mauvaise pour « assure-toi que mon appli est sans bugs » parce que ce n’est pas une tâche — c’est un vœu.
L’autre chose pour laquelle les créateurs d’applis avec IA sont doués, c’est rejouer votre bug. Si vous décrivez ce que vous avez fait, ce que vous attendiez et ce qui s’est passé, le créateur peut généralement remonter le fil du code et proposer une correction. La discipline qu’il vous faut, c’est de noter ces trois choses clairement. La plupart des signalements de bugs de débutants sont une variante de « ça ne marche pas ». La plupart des signalements de bugs réparables sont « j’ai cliqué sur X, j’attendais Y, j’ai eu Z ».
Tester, c’est lire, pas seulement cliquer
Une dernière chose. Vous n’avez pas besoin de comprendre chaque ligne de code de votre appli créée avec l’IA pour bien la tester. Mais vous devriez au moins survoler. Ouvrez le fichier que l’IA vient de modifier. Lisez la fonction qu’elle a ajoutée. Pas besoin de savoir ce que signifie chaque mot-clé — vous avez besoin de savoir si la fonction semble faire ce que vous avez demandé.
Beaucoup de bugs dans les applis créées avec l’IA ne sont pas « le code est cassé ». Ce sont « le code fait quelque chose de légèrement différent de ce que vous vouliez ». Un champ s’enregistre au mauvais endroit. Un bouton met à jour une chose mais pas la chose liée. Un bouton « supprimer » masque au lieu de supprimer. Vous ne pouvez pas attraper ça sans lire ce qui a réellement été construit.
Traitez le code comme quelque chose que vous pouvez auditer, pas quelque chose que vous devez écrire. C’est la différence entre une appli créée avec l’IA en laquelle vous avez confiance et une appli dont vous espérez juste qu’elle marche.
La version simple
Si vous ne retenez qu’une chose : écrivez les deux listes, cassez des choses exprès, et décidez à quel niveau d’« assez bon » vous livrez. La plupart des bugs d’une appli créée avec l’IA ne sont pas subtils. Ils sont posés sur la liste des chemins malheureux que personne n’a pris la peine d’écrire.
Si vous voulez un petit devoir : prenez une appli que vous avez créée et essayez quatre choses — soumettre un formulaire vide, actualiser en plein parcours, modifier un enregistrement et le vérifier le lendemain, et demander à un ami de l’utiliser sans que vous le regardiez. Tout ce qui casse, c’est votre vraie liste de bugs. Le reste, c’est de la procrastination.