Le code, ça coûte cher, mais les POC, c'est autre chose

J'entends sans arrêt l'expression « le code, ça ne coûte pas cher ».

Je ne sais pas qui l’a inventée. Mais celui ou celle qui l’a dite n’a clairement jamais vu une facture d’Anthropic.

Je comprends ce qu’ils veulent dire. Le coût d’écriture d’une ligne de code a chuté, l’IA s’occupe de la plupart de la saisie, tu connais la suite. D’accord. Mais cette phrase est provocante d’une manière qui n’aide personne, surtout pas les ingénieurs présents. « Le code est accessible » passe mieux. Moins de fanfaronnade, plus d’honnêteté.

Quoi qu’il en soit, voilà la phrase que mon ami Guillaume m’a donnée et qui m’a enfin fait comprendre le fond du problème : « Ma petite fille sait écrire du code. Ça ne fait pas d’elle une ingénieure. »

Exactement. Parce que ce qui est devenu bon marché, ce n’est pas l’ingénierie. Ce n’est même pas le code, en réalité. Ce qui est devenu bon marché, c’est la preuve de concept. Ce petit truc de fortune qui fonctionne et qui permet de démontrer une idée. Cet artefact pour lequel un responsable marketing comme moi avait autrefois besoin d’un développeur expérimenté pour le créer.

La meilleure façon de le dire : les POC sont bon marché aujourd’hui.

Je suis bien placé pour le savoir. C’est mon métier.

Ce que signifie réellement « les POC sont bon marché »

Il y a quelques mois, si je voulais présenter une idée de fonctionnalité, j’avais trois options.

Rédiger un cahier des charges long et minutieux en espérant qu’on le lise. Créer une maquette Figma qui a l’air aboutie mais sur laquelle on ne peut pas cliquer. Ou supplier un ingénieur de me consacrer une heure pour créer une maquette.

Maintenant, j’en ai une quatrième : coder moi-même une version fonctionnelle à l’instinct (j’utilise ce terme exactement une fois pour le référencement ; après ça, on parle de « développement assisté par IA », ce qui revient au même mais sonne plus sophistiqué et est plus difficile à balayer d’un revers de main lors d’une réunion du conseil d’administration).

L’astuce, ce n’est pas que j’ai appris à coder. Je n’ai pas appris. L’astuce, c’est que le modèle se charge de la partie technique et que je me charge du jugement sur le produit. Je décris l’idée comme si je brieffais un ingénieur senior. Je lis ce que ça me renvoie. Je peaufine le tout jusqu’à ce que ce que j’ai sous les yeux corresponde à ce que j’ai en tête. Deux heures, peut-être trois. Puis je le partage.

Andrej Karpathy a inventé ce terme en février 2025. Sur Internet, les avis divergeaient pour savoir si on « code vraiment » quand on fait ça. Mais la question posée n’était pas la bonne. La bonne question, c’est de savoir si le résultat fait avancer la discussion. Et c’est le cas. À coup sûr. À chaque fois.

La fille de Guillaume n’est pas ingénieure. Mais elle pourrait désormais créer un prototype d’une idée. Son prof aussi. Et ton PMM aussi.

Le modèle à l’envers

Voici la partie à laquelle je ne m’attendais pas.

Mes amis ingénieurs font un travail de positionnement qui est meilleur que certaines des choses que je livrais autrefois.

Pas tout, bien sûr. Ils ne vont pas me piquer mon boulot. Mais sur certains aspects précis du travail, notamment quand il s’agit de trouver le bon angle pour une fonctionnalité, la bonne façon de la présenter à un client, ou l’argument concurrentiel qui fait mouche lors d’une démo, mes amis ingénieurs reviennent avec des ébauches très convaincantes.

Le schéma est le même que le mien, mais à l’envers.

On leur donne les bases : le profil client cible (ICP), les personas, les habitudes d’achat, les concurrents, et la façon dont nos clients parlent réellement du problème. Ils alimentent tout ça dans une IA avec la fonctionnalité qu’ils viennent de créer, et ils reviennent avec des angles de positionnement que j’aurais mis une semaine à trouver lors d’un atelier avec l’équipe marketing.

L’IA n’a pas fait ça toute seule. Elle avait besoin du contexte. Ce contexte, c’est la partie qui revient vraiment au marketing. Mais la synthèse, ce moment où tu fixes le brief et où tu essaies de trouver la phrase qui fait que tout s’imbrique, l’IA est douée pour ça quand tu lui donnes les bonnes données.

C’est la même dynamique que pour mes POC. L’IA fait le gros du boulot. L’humain se charge de juger de ce qui est vraiment juste. Des rôles différents de chaque côté de l’équipe.

Ce que ça implique pour le fonctionnement des équipes

Ce n’est pas un article du genre « les marketeurs devraient apprendre à coder ». Ni un article du genre « les ingénieurs devraient apprendre le marketing ». Ces approches passent à côté de l’essentiel.

Ce qui se passe réellement : le cerveau collectif d’une petite équipe s’est considérablement agrandi. Le développement assisté par l’IA a permis aux non-ingénieurs d’accéder à des prototypes fonctionnels. Le positionnement assisté par l’IA a permis aux non-spécialistes du marketing d’accéder à des angles d’approche percutants. Les métiers n’ont pas changé. La clôture qui les séparait s’est dotée de nombreuses nouvelles portes.

Les équipes qui comprennent ça rapidement finissent par avoir des boucles de rétroaction plus courtes. Le PMM arrive à la réunion de planification avec un prototype fonctionnel. L’ingénieur arrive à la réunion de lancement avec trois ébauches de positionnement. Personne ne part d’une page blanche. La discussion saute les 60 % premiers et passe directement à la partie où l’équipe prend réellement une décision.

Les équipes qui ne comprennent pas ça continuent à considérer ces processus comme des voies à sens unique. Le PMM rédige le brief, l’ingénieur écrit le code, aucun des deux ne touche au travail de l’autre. Même rythme qu’il y a cinq ans. Pire encore, d’ailleurs, parce que tout le monde avance plus vite.

Le compromis que je te dois

Le fait que les POC ne coûtent pas cher ne veut pas dire qu’ils sont sans risque.

Le plus gros risque, ce n’est pas le code. C’est la réunion qui suit. Un POC fonctionnel donne l’illusion d’être abouti, et la question qui vient naturellement après, c’est « on le lance ? ». C’est là que les équipes se retrouvent en difficulté. Le code que j’écris en un après-midi n’est pas celui que l’on devrait présenter aux clients. Gartner a averti que « les approches “prompt-to-app” adoptées par les développeurs amateurs augmenteront les défauts logiciels de 2 500 % » d’ici 2028. Ils ont raison sur ce qui se passe quand personne ne trace la ligne entre le POC et la production.

Trace cette limite à voix haute. Le POC, c’est la conversation. Le produit, c’est ce qui est construit après, par des ingénieurs, avec rigueur. L’ébauche de positionnement de l’ingénieur, c’est l’étincelle. Le texte de lancement, c’est ce que le marketing construit ensuite, avec savoir-faire. Ne livre aucun des deux directement de l’IA au client.

Retour à la facture d’Anthropic

Je veux être honnête sur un autre point. Le code, ça coûte cher. Les jetons coûtent de l’argent réel, et j’ai vu la facture de mon équipe grimper chaque mois à mesure qu’on s’investit davantage dans ce processus. Le coût a simplement changé de nature. Avant, c’était les heures de travail des développeurs. Maintenant, c’est la puissance de calcul. Le calcul reste largement rentable, mais faire comme si le coût avait disparu, c’est comme ça que les équipes se retrouvent avec des surprises trimestrielles.

La fille de Guillaume n’est toujours pas ingénieure. Mais elle peut désormais créer un prototype à partir d’une idée. Tout comme mon équipe PMM. Tout comme mon ingénieur chargé du positionnement. Les intitulés de poste ne changent pas. Ce sont les outils qui changent.

C’est ce qu’on devrait dire haut et fort, lors des réunions où l’organigramme continue de faire comme si ces trois métiers vivaient dans trois bureaux différents.

Le code est accessible. Les POC ne coûtent pas cher. L’équipe, c’est bien plus que le nombre de personnes.

Dans le prochain article, je t’expliquerai en détail comment je construis ces prototypes : Claude Code, Upsun, ainsi que les compétences spécifiques, les plugins et les MCP qui permettent à un responsable marketing produit de livrer en un après-midi quelque chose sur quoi un vrai ingénieur peut réagir.