Depuis que je m’investis dans l’IA, mes requêtes (prompts) deviennent de plus en plus pointues. J’entends de plus en plus de gens qui posts sur le NoCode, que l’AI remplace des développeurs et mettent à la rue des milliers de gens.

N’ayant pas le recul pour dire si c’est exact, j’ai décidé de me faire ma propre idée. Ayant quelques décennies d’expérience dans le codage (C, C#), je me suis fixé comme objectif de développer une petite app dans un environnement que je ne maitrise pas. Le but est de piloter l’IA pour qu’elle fasse tout le travaille de codage sans que j’écrive une seule ligne de code.

Je me suis donc lancé dans l’aventure… sans écrire une seule ligne de code.

Pour répondre à tous mes critères j’ai choisi une petite web application avec un viewer fun htlm. Je suis dans un environnement le plus simple que je connaisse :

• Environnement Windows
• Un navigateur internet
• Une connexion à l’IA via le chat.

Et le processus itératif devient donc :

• Je donne une directive à l’IA via le chat
• Elle me renvoie un fichier zippé avec toute le code html de l’application
• Je dézippe
• Je lance le fichier à la racine index.html
• Je visualise le résultat
• J’analyse le comportement de l’application
• Je donne une nouvelle directive

Ainsi en pilotant une IA dans le navigateur, itération après itération, je suis parvenu à obtenir un petit visualiseur graphique stable (zoom, navigation, mini-carte, capture…).

Sur le papier, c’est la promesse attendue : « l’IA code, donc je peux créer vite ». Dans la pratique, j’ai investi ~60 heures pour un premier niveau fonctionnel. Et cette durée est logique dès qu’on comprend où part le temps : la complexité ne disparaît pas, elle change de place. On ne code pas… mais on conçoit, on teste, on corrige, on versionne, on arbitre.

Ce que j’ai appris (et que je ne soupçonnais pas au départ)

1. La difficulté n’est pas le code, c’est la précision.
   Une IA exécute. Elle ne devine pas. Si votre demande est floue, elle « comble les trous » à sa façon. Le résultat peut être cohérent… mais pas celui que vous aviez en tête. J’ai découvert un écart permanent entre l’interface imaginée et l’interface obtenue. Une grande partie des itérations vient de là.

• Les erreurs de conception… viennent souvent du concepteur.
  Quand on n’a pas le métier, on choisit parfois une mauvaise interface au départ : trop de boutons, mauvais emplacement, panneaux mal hiérarchisés. Ensuite on “bricole” au lieu de reposer des règles. Exemple classique : un panneau qui devait avoir un en-tête fixe + une zone défilante… mais on ne le précise pas. Résultat : tout défile, le bouton “fermer” disparaît, et on tourne en rond. J’ai appris à formuler des contraintes simples : « en-tête fixe », « un seul bouton X », « aucun débordement », « le défilement ne concerne que le contenu ».

• Le vrai moteur du projet, c’est la boucle itérative.
  Conception d’une fonction → mise en œuvre par l’IA → test → bugs → corrections → (parfois) remise en cause du design → stabilisation. Une fonction n’est pas “faite” quand elle apparaît ; elle est faite quand elle reste stable après trois autres évolutions. Et oui : parfois, ce n’était pas un bug… mais une mauvaise idée de départ.

• Sans discipline de versions, vous perdez le contrôle.
  La règle qui m’a sauvé : 1 livraison = 1 version testée. Si une correction casse autre chose (régression), je reviens à la dernière version stable. Sans cela, on se retrouve avec le fameux “ça marchait hier” sans savoir pourquoi. J’ai aussi tenu un mini-journal des changements (3 lignes par version) : ce qui a changé, ce qui est stable, ce qui reste fragile.

• Développer via une IA dans le navigateur a ses propres contraintes.
  À mesure que le fil grossit (texte, images, code), le navigateur peut ralentir, bloquer, ou rendre la session pénible. Oui, j’ai dû parfois changer de fil de discussion pour retrouver une interface fluide. Le remède : externaliser le “socle” du projet (règles, invariants, version de référence, journal des changements) pour repartir proprement sans tout réexpliquer.

• Pour avancer, il faut tenir à la fois les rênes de l’IA et ne pas se décourager.

C’est sans doute le plus dure de l’exercice. Le facteur humain est primordial dans le processus global d’itérations. Il faut persévérer, savoir négocier avec l’IA par ce qu’on est à un point de blocage, se remettre en question.

Ce que je n’avais pas anticipé : le « niveau technique minimal »
Même sans coder, on apprend des notions : tester sur plusieurs tailles d’écran, comprendre qu’un navigateur peut bloquer certaines fonctions en mode fichier local, savoir relancer proprement, organiser des dossiers, et surtout décrire un problème comme un scénario (“je clique ici → il se passe ça → j’attends ça”). C’est une compétence transférable : elle ressemble à de la recette/test qualité.

Qui peut investir 60 heures ?
Si votre besoin est urgent, ce n’est pas la voie la plus rentable. En revanche, si vous cherchez de l’autonomie, une montée en compétence, ou un prototype, c’est très formateur. Le vrai bénéfice, pour moi, c’est d’avoir confirmé ce que je sais d’une chaîne complète d’un produit logiciel : conception, arbitrages, itérations, stabilité, robustesse. On sort de l’illusion “l’app = un écran avec des boutons”.

Ce que je referais (et ce que j’éviterais)

✅ Je referais :
• Une demande = un objectif mesurable.
• Toujours préciser : contexte → objectif → contraintes → test.
• Une fonction à la fois, puis stabilisation.
• Invariants écrits (“ne touche pas à…”, “l’en-tête reste fixe”, etc.).
• Versioning systématique + mini-journal des changements.

❌ J’éviterais :
• Les demandes “améliore tout” (ça déclenche des refontes et des régressions).
• Les refactorings globaux trop tôt.
• Ajouter des nouveautés tant qu’un bug critique n’est pas clos.

Conclusion de mon retour d’expérience :
Créer une application “sans coder” est accessible… mais ce n’est pas gratuit. L’IA accélère la production de code ; elle n’accélère pas automatiquement la clarté, la conception et la validation. Le vrai métier, ici, c’est de piloter : observer, décider, contraindre, tester.

J’ai écrit un article complet sur la procédure pour créer une application sans codage. Je vous propose de vous la partager. Pour cela, faite moi un commentaire avec simplement « PDF ».  Je vous enverrai le lien de téléchargement de mon étude sur « créer une application sans coder ».

Si vous envisagez cette voie, je serai ravi d’échanger : quel type d’outil voulez-vous créer, et quelle serait votre première fonctionnalité de produit minimum viable (MVP) ?

#IA #Productivité #NoCode #Développement #UX #PromptEngineering #RetourDExperience