Parler à une IA qui code : la nouvelle compétence métier

Tu n'as plus besoin d'apprendre à coder pour faire faire des choses à une machine. Tu as besoin d'apprendre à être précise. Ce n'est pas la même chose.

Une base Access pour suivre les contrats saisonniers d'un hôtel. C'était ma première fois. Je ne savais pas coder. Personne dans l'équipe n'allait la construire à ma place, alors je me suis débrouillée. J'ai dit à la machine ce que je voulais, à peu près dans sa langue à elle : des tables, des relations, des requêtes qui plantaient quand on éternuait à côté.

Si j'ai compris deux trois bribes de langage avec le temps, je ne sais toujours pas coder.

Mon rapport aux ordinateurs a longtemps ressemblé à une tentative de communication avec quelqu'un dont je ne parlais pas la langue. Je chopais des mots à force de fréquentation. La syntaxe d'une formule Excel. Le mot juste pour faire un filtre dans Access. Le bon clic dans Zapier pour relier deux outils. La logique de fonctionnement de Airtable. Mais la grammaire n'est jamais venue. Je n'ai jamais pu écrire une phrase de zéro. Je copiais, je collais, je modifiais ce que d'autres avaient écrit, je tâtonnais jusqu'à ce que ça marche.

Avant Access il y a eu Excel et ses macros que je bricolais le dimanche soir. Après Access il y a eu Wordpress, puis Softr, Airtable, Zapier. Aujourd'hui c'est Claude, Lovable, Claude Code. À chaque étape, le même bricolage : décrire ce que je voulais obtenir avec les bouts de langue que j'avais, et combler le reste avec de la patience et des recherches Google.

Ce qui a changé en deux ans, ce n'est pas que les machines sont devenues intelligentes. C'est qu'elles font la traduction pour moi. Je décris en français. Elles écrivent dans leur langue à elles.

Avant 2025, chaque outil avait sa propre logique à apprendre

Pour faire fonctionner un outil, il fallait d'abord apprendre comment il pensait. Excel avait ses formules, avec une syntaxe à respecter au caractère près. Access avait ses requêtes, qu'il fallait construire en respectant ses règles à lui. Zapier avait ses connecteurs, ses déclencheurs, ses étapes, et chaque connecteur demandait de comprendre ce qu'il attendait en entrée et ce qu'il rendait en sortie.

Pas besoin d'être développeuse pour utiliser tout ça. Mais besoin de temps. Quand je voulais faire sortir un tableau d'un logiciel comptable, j'apprenais ce logiciel-là. Quand je voulais le pousser dans un outil de discussion d'équipe, j'apprenais cet outil-là. Chaque service avait sa logique propre, et à chaque nouveau projet j'ajoutais une couche.

Avec Claude, Lovable et Claude Code, je décris en français ce que je veux. La machine traduit. Si le résultat n'est pas celui que j'avais en tête, je précise. Elle corrige.

C'est un glissement. Mais ce glissement déplace la compétence essentielle. Avant, c'était la maîtrise de chaque dialecte. Maintenant, c'est la précision de la description.

Trois outils, trois portées, le même geste

Ces derniers mois, j'ai commencé à utiliser trois outils, dans l'ordre chronologique, qui changent la manière dont je travaillais jusqu'à maintenant.

Claude dans le chat. Je lui parle comme je parlerais à une personne très compétente qui n'a aucun contexte sur moi ni sur ce que je fais. Je décris ce que je veux, il répond, je précise, il affine. Je m'en sers pour structurer un argument, analyser un document long, écrire un premier jet, réfléchir à voix haute sur un problème de produit, et aussi pour des tâches très concrètes sur des fichiers.

J'ai eu un fichier d'export récemment. Plusieurs centaines de lignes mal formatées, des doublons, des champs vides à des endroits aléatoires. Le genre de fichier qu'on nettoie à la main en jurant, ou qu'on envoie à un prestataire en croisant les doigts pour qu'il revienne propre. Je l'ai déposé dans Claude. Je lui ai décrit le problème en français, pas en termes techniques. « Voilà ce que j'ai. Voilà ce que je veux obtenir. Voilà les règles de nettoyage : si tel champ est vide, va chercher la valeur dans cette autre colonne. Si tel format ne correspond pas, signale-le mais ne supprime pas la ligne. » Il a fait le travail, m'a montré le résultat. Un cas que je n'avais pas anticipé apparaissait. Je l'ai décrit. Il a corrigé. Vingt minutes plus tard le fichier était propre.

Je n'ai pas écrit une ligne de code. J'ai décrit un problème métier avec précision, j'ai itéré quand le résultat ne correspondait pas exactement, et j'ai obtenu ce que je voulais. La qualité de ce que j'obtiens dépend presque entièrement de la qualité de ce que je donne. Pas de ma maîtrise technique. De ma précision. Une demande floue donne une réponse générique. Une demande précise, avec le contexte, les contraintes et l'objectif réel, donne quelque chose d'utilisable. C'est la compétence de base, et elle s'apprend.

Lovable. Tu décris une application que tu veux construire, et Lovable la construit. Pas un prototype sur papier : une vraie application qui tourne dans un navigateur, avec ses pages, ses boutons, ses formulaires, mais aussi tout ce qu'il y a derrière. La base de données qui stocke les informations des utilisateurs, les règles qui décident qui a le droit de voir quoi, les connexions aux autres services. Tout ça, Lovable l'installe en même temps que l'interface.

J'ai construit les premières versions de Pimpela avec Lovable. Pimpela, c'est une app qui transforme une photo de ta pièce selon ton style déco et ton niveau bricolo, avec un plan d'action orienté DIY et seconde main. Le concept était clair dans ma tête depuis quelques semaines. Ce qui me manquait, c'était la capacité à en faire quelque chose de tangible vite, sans attendre un développeur. J'ai décrit ce que je voulais à Lovable. L'application s'est construite, écran après écran, avec la base de données qui se mettait à jour en parallèle pour stocker les pièces, les utilisatrices, leurs choix. J'ai itéré, précisé, corrigé. En quelques jours j'avais quelque chose à montrer à de vraies utilisatrices.

Claude Code. Lovable m'a permis de construire vite, mais avec une limite. Lovable est très intégré, ce qui le rend simple à prendre en main, et ça devient rapidement cher quand un produit avance. Claude Code, c'est l'étape d'après. Plus d'autonomie, moins d'abonnements à empiler, et la possibilité d'aller plus loin dans le développement d'outils.

C'est le même Claude que dans le chat, branché directement dans ton ordinateur. Il ne répond pas dans une fenêtre, il agit. Il lit tes fichiers, écrit du code, exécute des commandes, teste, corrige, recommence. Le terminal, c'est juste un endroit où tu tapes des trucs et où la machine te répond. Pas plus mystérieux qu'une barre de recherche Google, sauf que la mise en forme est moins jolie.

Le geste reste le même que dans le chat. Je décris ce que je veux. La différence n'est pas dans la façon de parler à la machine, elle est dans ce qu'on lui demande. Le chat est parfait pour les choses ponctuelles : un fichier à nettoyer, un texte à analyser, une réponse à une question. Lovable, pour aller vite et tester un produit. Claude Code, pour les chantiers qui durent et qu'on veut faire grandir.

Pourquoi les non-tech ont parfois un avantage

Les personnes qui ont le plus de mal avec ces outils ne sont pas toujours les moins techniques. Parfois c'est l'inverse.

Les développeurs ont des habitudes de pensée précises sur la façon dont les machines fonctionnent. Ces habitudes sont précieuses pour écrire du code. Elles peuvent devenir un frein quand l'IA fait la traduction à leur place, parce qu'ils veulent contrôler le comment au lieu de décrire le quoi.

Cette habitude, je ne l'ai jamais eue. Je me suis toujours arrêtée à la partie description du problème métier. La suite, le comment, la mécanique sous le capot, je l'ai laissée aux outils. Je ne savais pas ce qui s'y passait. Faiblesse ou pragmatisme, je vous laisse en juger, moi, je savais ce que je voulais obtenir.

Et c'est exactement la posture que demandent Claude, Lovable et Claude Code.

La RH qui sait décrire son process de recrutement, les critères qu'elle applique, les exceptions qu'elle gère, les pièges qu'elle a appris à reconnaître, a un avantage réel sur quelqu'un qui sait coder mais ne comprend pas le métier. La community manager qui sait exactement quel ton, quel format, quelle fréquence elle veut, obtiendra de meilleurs résultats que quelqu'un qui connaît les outils mais qui n'a pas réfléchi à ce qu'il voulait vraiment produire. La financière qui connaît ses propres reportings dans le détail, qui sait quels chiffres elle veut voir en premier le lundi matin, qui sait quelle anomalie déclenche chez elle un signal d'alerte, sait formuler la chose mieux que n'importe quel prestataire.

La compétence technique n'est pas inutile. Mais elle n'est plus le goulot d'étranglement. Le goulot, c'est la clarté sur ce qu'on veut.

Apprendre à être précise, c'est un vrai apprentissage

Décrire précisément, ça s'apprend. Et au début on est mauvaise. Mes premières semaines avec Claude, j'obtenais des résultats décevants et je ne comprenais pas pourquoi. La machine était trop générique, trop prudente, trop loin de ce dont j'avais besoin.

Le problème c'était moi. Mes descriptions étaient floues. Je donnais l'objectif sans le contexte. Je donnais le contexte sans les contraintes. Je donnais les contraintes sans les exemples de ce que je ne voulais surtout pas. Apprendre à être précise avec une IA, c'est apprendre à externaliser sa pensée avec rigueur, à sortir de sa tête les hypothèses implicites qu'on ne formule jamais parce qu'on les croit évidentes. Elles ne le sont pas pour une machine, et d'ailleurs elles ne le sont pas non plus pour les humains. On s'en sort juste mieux par habitude commune.

Il y a aussi la patience de l'itération. La première réponse est rarement la bonne, c'est normal. Sur un chantier dans Claude Code, ça peut prendre cinq ou six allers-retours avant d'avoir un script qui fait exactement ce que je voulais. C'est largement plus rapide que d'apprendre Python.

Et puis il y a les moments où la machine part dans la mauvaise direction parce que j'ai été imprécise sur un détail. Elle construit quelque chose de cohérent avec ce que je lui ai dit, mais pas avec ce que je voulais vraiment. Ces moments-là m'apprennent beaucoup. Ils me forcent à identifier l'endroit exact où ma description était insuffisante, et à reconnaître que la description était le problème.

Ce que je construis, chaque semaine.

Les projets en cours, ce qui marche, ce qui casse. Pas de bruit.