Que faire quand votre appli créée avec l'IA casse à 2 h du matin (et que vous n'êtes pas développeur)

Vous avez créé une appli sans écrire la moindre ligne de code. Elle a marché toute la semaine. Puis un utilisateur vous écrit à 1 h 47 du matin pour dire que le bouton d’inscription ne fait rien, et vous vous réveillez devant votre téléphone qui s’allume sur la table de nuit.

Si vous n’avez jamais eu à réparer une appli en ligne, ce moment peut sembler horrible. Vous ne lisez pas le code. Vous ne savez pas vraiment ce que « la base de données » veut dire. Vous n’êtes pas sûr que ce soit cassé-cassé ou juste-bizarre, et les gens qui vous aideraient d’habitude dorment.

Voici un mode d’emploi calme et ordonné pour ce qu’il faut faire quand une appli créée avec l’IA casse et que vous ne savez pas écrire de code. L’essentiel consiste à ne pas aggraver les choses, ce dont personne ne vous prévient.

D’abord : ne redéployez pas

Il y a quelque part dans votre créateur d’applis avec IA un bouton qui dit quelque chose comme « republier », « redéployer » ou « livrer ». Vous allez avoir envie d’appuyer dessus. Ne le faites pas, pas encore.

Appuyer sur redéployer sur une appli à moitié cassée peut figer l’état cassé, balayer les informations de débogage qui traînaient, et compliquer la tâche de quiconque — y compris le créateur d’applis avec IA lui-même — pour comprendre ce qui a mal tourné.

Le premier réflexe est toujours de regarder, pas d’agir. Vous n’avez même pas encore confirmé ce qui est cassé.

Étape 1 — Reproduisez le problème vous-même

Ouvrez l’appli dans une fenêtre de navigateur neuve — le mode incognito ou navigation privée est idéal, parce qu’il supprime toute ancienne connexion ou cache qui pourrait faire que les choses se comportent différemment pour vous que pour votre utilisateur.

Essayez de faire exactement ce que l’utilisateur a signalé. S’il a dit que le bouton d’inscription ne marche pas, essayez de vous inscrire. S’il a dit que le tableau de bord est vide, essayez de vous connecter et de l’afficher.

Vous cherchez l’une de ces trois choses :

C’est cassé pour tout le monde. Vous tombez sur le même problème. C’est en fait le plus facile à corriger, parce que c’est constant.
Ça marche pour vous. C’est le scénario le plus difficile, parce que quelque chose dans la situation propre à l’utilisateur (son navigateur, son compte, ses données) est en cause.
C’est intermittent. Ça marche une fois et casse la fois suivante. C’est le plus stressant mais aussi le plus instructif — ça veut généralement dire que quelque chose dépasse un délai ou arrive à court d’une ressource.

Notez lequel des trois vous avez constaté. Vous en aurez besoin quand vous demanderez de l’aide.

Étape 2 — Vérifiez les choses externes évidentes avant d’accuser votre appli

Un nombre surprenant de moments « mon appli est cassée » ne viennent pas de votre appli. Avant de vous enfoncer dans votre créateur d’applis avec IA, vérifiez :

Internet lui-même fonctionne-t-il ? Ouvrez deux ou trois autres sites. Si votre wifi est capricieux, votre appli va peut-être bien et c’est peut-être vous qui êtes cassé.
Le créateur d’applis avec IA lui-même a-t-il eu une panne ? La plupart des créateurs d’applis avec IA ont une page de statut (cherchez le nom du produit suivi de « status »). S’ils passent une mauvaise nuit, vous n’avez rien d’autre à chercher.
L’un de vos outils connectés est-il tombé ? Si votre appli utilise Stripe pour les paiements, un service d’e-mail pour les notifications, ou un service de base de données pour stocker les données, n’importe lequel peut connaître une panne. Chacun a sa propre page de statut. Vérifiez ceux dont votre appli dépend.

Environ une fois sur cinq, la réponse est « ce n’est pas vraiment mon appli », et vous pouvez retourner vous coucher.

Étape 3 — Regardez le message d’erreur, même s’il vous fait peur

Si votre appli affiche un écran avec du texte dessus — même un texte d’apparence incompréhensible — lisez-le. Faites une capture d’écran. Surtout s’il y a une longue chaîne de lettres et de chiffres (les gens appellent ça une « stack trace » ; ça ressemble à de la soupe de lettres, mais c’est la chose la plus utile à avoir quand on demande de l’aide).

La plupart des créateurs d’applis avec IA ont aussi un endroit où voir les erreurs récentes. Ça peut s’appeler Logs, Activité, Erreurs ou Console. Ouvrez-le. Vous n’avez pas besoin de comprendre la plupart de ce que vous voyez — vous cherchez le texte rouge le plus récent ou l’erreur la plus récente, et l’heure à laquelle elle s’est produite. L’heure compte : une erreur d’hier matin n’est probablement pas la raison pour laquelle votre utilisateur n’a pas pu s’inscrire à l’instant.

Copiez cette erreur. Vous allez la coller quelque part d’utile dans une minute.

Étape 4 — Demandez au créateur d’applis avec IA ce qui a changé

C’est le réflexe que les créateurs non techniques sous-exploitent le plus. Ouvrez le chat avec votre créateur d’applis avec IA et dites, en langage clair :

« Mon appli est cassée. Les utilisateurs ne peuvent pas s’inscrire — le bouton ne fait rien. Voici l’erreur tirée des logs : [colle-la]. Qu’est-ce qui a changé ces dernières 24 heures, et qu’est-ce qui pourrait en être la cause ? »

Un bon créateur d’applis avec IA vous dira quel changement récent en est le plus probablement responsable. Parfois vous le reconnaîtrez immédiatement (« ah, je lui ai demandé hier de rendre le formulaire plus joli et ça a sûrement cassé la logique d’envoi »). Parfois il pointera vers quelque chose que vous ne vous souvenez pas avoir touché, ce qui est aussi utile — ça veut dire qu’un changement automatique s’est produit, comme un outil connecté qui se met à jour.

Ne laissez pas le créateur d’applis avec IA commencer à corriger pour autant. Vous êtes encore en mode diagnostic. La façon la plus courante que j’ai vue les gens aggraver un petit problème, c’est de laisser une IA se mettre à « réparer » des choses avant que quiconque ne comprenne ce qui est cassé.

Étape 5 — Décidez si vous revenez en arrière

Presque tous les créateurs d’applis avec IA vous permettent de revenir à une version antérieure de votre appli. Ça s’appelle parfois « historique », « versions », « points de contrôle » ou « rollback ».

Si vous vous souvenez clairement d’une heure ou d’un jour où l’appli marchait, revenir à cette version est le mouvement le plus fiable qui soit. Ça vous coûte les changements faits entre-temps (que vous ne vouliez peut-être même plus), et ça vous donne une appli qui marche à votre réveil.

Une bonne règle : si la chose cassée est quelque chose que les utilisateurs font tous les jours (inscription, connexion, paiement), revenez d’abord en arrière et corrigez ensuite. Fonctionnel-mais-périmé bat cassé-mais-à-jour à tous les coups.

Si la chose cassée est une fonctionnalité que vous avez ajoutée aujourd’hui et dont personne ne dépend encore, vous pouvez la laisser cassée jusqu’au matin et la corriger l’esprit clair.

Étape 6 — Si vous devez laisser le créateur d’applis avec IA la réparer

Si le retour en arrière est impossible, ou que vous avez décidé de ne pas le faire, laissez alors le créateur d’applis avec IA proposer une correction. Deux choses à garder en tête pendant qu’il le fait :

Lisez ce qu’il prévoit de modifier avant d’approuver. Vous ne comprendrez pas tout, mais vous pouvez repérer s’il modifie une seule chose ciblée ou s’il réécrit la moitié de l’appli. De petits changements ciblés sont bien plus sûrs que des changements balayants à 2 h du matin.

Testez la correction de la façon la plus terre à terre possible. Ne vous contentez pas de demander « c’est réparé ? » et de croire la réponse. Allez vous-même dans l’appli, dans une fenêtre incognito, et faites la chose qui était cassée. Si la correction a marché, la chose cassée marche maintenant. Sinon, n’acceptez pas le changement juste parce que le créateur d’applis avec IA a dit qu’il marchait.

Étape 7 — Répondez à l’utilisateur, même sans avoir réparé

L’utilisateur qui vous a écrit à 1 h 47 ne s’attend pas à ce que vous soyez en ligne. Mais si vous l’êtes, une courte réponse compte plus qu’une correction :

« Merci de m’avoir prévenu — je regarde ça tout de suite. Je vous fais signe dès que c’est de nouveau opérationnel. »

Si c’est un utilisateur payant, ce seul message fait la différence entre quelqu’un qui dira aux gens que vous répondez vite et quelqu’un qui dira que vous l’avez ignoré. La correction peut attendre demain matin. La réponse, non.

La leçon plus large : construisez votre appli en supposant qu’elle peut casser

Si vous avez trouvé ça stressant, la bonne nouvelle, c’est que l’expérience va remodeler votre façon de construire. Après votre premier incident de 2 h du matin, vous commencerez à faire les choses différemment :

Vous ajouterez une vérification d’état. Une page simple qui vous dit si les parties importantes de votre appli fonctionnent, pour ne pas avoir à vous connecter pour le savoir.
Vous garderez une sauvegarde des données utilisateur. La plupart des créateurs d’applis avec IA exportent vos données sur demande. Le faire une fois par semaine prend 30 secondes et vous sauve dans le pire des cas.
Vous noterez de quoi votre appli dépend. Une courte liste de chaque outil connecté (paiements, e-mail, base de données, stockage), pour qu’au moment où quelque chose casse à 2 h du matin, vous ayez une checklist au lieu de suppositions.
Vous changerez une chose à la fois. Quand vous faites 10 changements d’un coup et que l’appli casse, vous n’avez aucune idée duquel l’a cassée. Quand vous changez une chose à la fois, vous le savez.

Vous pouvez créer une appli sans coder. Vous pouvez aussi en maintenir une en marche sans être développeur — mais les compétences en jeu sont différentes des compétences de création. Vous les apprenez surtout à la dure, généralement à une heure inopportune.

La bonne nouvelle : à chaque fois que ça arrive, ça fait moins peur. À la troisième fois, c’est agaçant au lieu d’effrayant. À la dixième, c’est juste un mardi comme un autre.