Modifier, valider, revenir en arrière : garder la main sur une application assemblée par l’IA

1

La première version est un point de départ

Quand l’IA assemble une application à partir de votre description, la première version arrive vite. Elle est souvent proche de ce que vous vouliez, rarement exacte. Un champ manque, un libellé prête à confusion, une règle s’applique un jour trop tôt. Ce n’est pas un échec. C’est le point de départ normal d’une phase d’ajustement.

Le vrai risque est ailleurs. Une première erreur se voit et se corrige. Ce qui coûte cher, c’est une modification qui casse en silence quelque chose qui fonctionnait : un écran que plus personne n’ouvre, un calcul qui change sans que l’on s’en aperçoive, un droit d’accès élargi par accident. Garder la main, c’est s’organiser pour que ces effets de bord n’existent pas, ou soient vus avant d’atteindre votre équipe.

2

Demander des modifications ciblées

La tentation, après une première version, est de tout redécrire. C’est la meilleure façon d’obtenir une deuxième version différente, pas une version meilleure. L’IA travaille mieux quand vous pointez l’élément exact : ce champ, cet écran, cette règle. Le reste ne bouge pas.

Trois habitudes rendent une demande de modification efficace. Désigner l’endroit précis. Demander une seule chose à la fois. Dire ce que vous avez vu et ce que vous attendiez à la place. Ce sont les mêmes habitudes que celles décrites dans Décrire son besoin à l’IA, appliquées à une application qui existe déjà.

• Bonne demande : « Sur l’écran Devis, le champ Remise accepte des valeurs négatives. Il devrait refuser tout montant inférieur à zéro. » Demande vague : « Le module devis ne marche pas bien. »
• Bonne demande : « Dans la liste des interventions, ajoutez une colonne Technicien, juste après la colonne Client. » Demande vague : « Il manque des infos dans les listes. »
• Bonne demande : « La règle qui bloque une facture sans bon de commande doit aussi s’appliquer aux notes de crédit. » Demande vague : « Revoyez toutes les règles de facturation. »
• Bonne demande : « Quand je clique sur Valider, la fiche se ferme sans message. Je m’attendais à une confirmation. » Demande vague : « Ça plante quand on valide. »

Une demande précise a un autre avantage : elle se vérifie. Vous savez exactement quoi regarder dans la version suivante, et vous voyez tout de suite si autre chose a bougé.

3

Quand quelque chose ne va pas

Une modification produit parfois un résultat inattendu. La réaction utile n’est pas de demander une nouvelle correction dans la foulée. C’est de décrire ce qui s’est passé, comme vous le feriez à un collègue : quel écran, quelle action, quel résultat. « Sur la fiche client, en cliquant sur Enregistrer, le numéro de TVA disparaît. »

Ensuite, laissez l’IA expliquer la cause avant de corriger. Une explication claire vous dit si le problème vient de la modification demandée, d’une règle plus ancienne ou d’un malentendu sur le besoin. Corriger sans comprendre revient à empiler des rustines : chaque correction en appelle une autre, et plus personne ne sait ce que fait l’application.

Une correction à la fois, vérifiée avant la suivante. Si deux problèmes apparaissent, traitez le plus important, contrôlez, puis passez au second. La lenteur apparente est une économie réelle.

4

Versions et retour en arrière

Une application assemblée par l’IA doit conserver chaque version. Pas seulement la dernière : toutes celles qui l’ont précédée. C’est cette mémoire qui rend les modifications sans danger. Vous pouvez comparer deux états, prévisualiser le nouveau avant de l’adopter, et revenir au précédent si le résultat ne convient pas.

Le principe se résume simplement : une modification qui ne vous convainc pas n’est pas gardée. Elle n’a rien cassé, elle n’a rien laissé derrière elle. Vous retrouvez l’état d’avant, exactement.

1. 01
   Prévisualiser

   Ouvrez la nouvelle version dans un espace de test, avec les écrans et les données de démonstration que votre équipe utilise. Rien n’a encore changé pour les utilisateurs.

2. 02
   Comparer

   Mettez la version précédente et la nouvelle côte à côte. Regardez d’abord l’élément modifié, puis les écrans voisins : c’est là que les effets de bord se cachent.

3. 03
   Décider

   Le résultat correspond à la demande et rien d’autre n’a bougé ? Vous validez. Un doute subsiste ? Vous demandez une explication ou une correction avant d’aller plus loin.

4. 04
   Publier ou revenir en arrière

   Vous publiez la version validée, ou vous revenez à la précédente en une seule action. Dans les deux cas, l’historique conserve la trace de ce qui a été essayé et de la décision prise.

Cette réversibilité change la façon de travailler. Vous osez essayer, parce qu’essayer ne coûte rien de définitif.

5

Valider avant la production

Entre la version que vous avez approuvée et le quotidien de votre équipe, il reste une étape : la validation. Elle se fait dans un environnement dédié, séparé de la production, où les personnes qui utiliseront l’application la testent réellement. Les cas normaux d’abord : créer un devis, planifier une intervention, clôturer un dossier. Puis les exceptions : un client sans adresse, une facture annulée, une date dans le passé.

C’est aussi le moment de revérifier les droits. Une modification peut, sans intention, ouvrir un écran à un rôle qui ne devait pas le voir, ou retirer un accès nécessaire. Avant chaque publication, la question est posée explicitement : qui voit quoi, qui peut modifier quoi. La réponse doit être la même qu’avant, sauf si vous avez demandé un changement.

Rien ne passe en production sans l’accord de votre équipe. Et cet accord laisse une trace : qui a approuvé quelle version, à quel moment, sur quelle base. C’est la même logique que celle décrite dans Automatiser sans retirer la décision humaine pour les automatisations : un seuil, une validation, une trace. Une application évolue selon les mêmes règles qu’une action automatisée.

Une version n’est pas terminée quand l’IA a fini. Elle est terminée quand votre équipe l’a approuvée.

6

Dans Neoo : chaque évolution garde un contrat clair

Dans Neoo, ce travail se fait avec Neoo Forge, l’atelier qui assemble vos applications avec l’IA. Vous décrivez votre métier, Forge assemble les écrans, les règles et les automatisations, reliés à vos données existantes. Et surtout, Forge vérifie chaque évolution avant de la publier.

Cette vérification porte sur cinq points : les dépendances entre l’application et le reste de votre système, les droits d’accès, la sécurité, les tests et la possibilité de revenir en arrière. Le compilateur de Forge est une porte de contrôle, pas une formalité. Une modification qui ne passe pas ces contrôles n’est pas publiée, et vous savez pourquoi.

Chaque capacité assemblée par Forge possède un responsable, une version, des droits et des tests. C’est ce qui permet aux évolutions de garder un contrat clair : vous savez ce que fait chaque élément, qui en répond, et ce qui change d’une version à l’autre. Le point de départ reste celui décrit dans Créer une application métier sans coder : votre description, vos mots, votre validation.

Vous pouvez voir comment Forge fonctionne sur la page Neoo Forge, ou en parler avec nous lors d’une démonstration.