À propos — Notes pour plus tard

Ça fait vingt ans que je construis des outils sans savoir coder.

D'abord Access et Excel. Je faisais des bases de données qui ressemblaient à des labyrinthes, avec des macros qui plantaient quand on éternuait à côté. Personne ne m'avait appris. J'avais lu la doc, essayé, cassé, recommencé. C'était lent, souvent moche, et ça marchait.

Puis Softr, Airtable, Zapier. Des outils qui m'ont permis de construire des choses un peu moins moches, un peu plus vite. Puis Claude et Lovable. Puis Claude Code. La liste s'allonge, la courbe s'accélère, mais le geste est le même depuis le début : j'ai une idée, je cherche comment la faire tenir debout, je bricole jusqu'à ce que ça tourne.

Pas de formation. Pas de diplôme d'ingénieure. Juste l'obstination de quelqu'un qui préfère comprendre par les mains.

Vingt ans de bricolage

Il faut que je sois honnête sur ce que « bricoler » veut dire dans mon cas.

Ce n'est pas de la modestie feinte. Je ne sais pas écrire du code de zéro. Je ne saurais pas construire une API de bout en bout sans aide. Pendant vingt ans, j'ai appris à utiliser des outils qui me permettaient de contourner cette limite, de construire des choses utiles sans jamais franchir la frontière du vrai développement.

Access, dans les années 2000, c'était déjà ça. Un outil qui permettait à quelqu'un comme moi, financière de formation, de construire des bases de données relationnelles sans écrire une ligne de SQL. Je me souviens d'un fichier de suivi de trésorerie que j'avais construit pour une petite structure. Trois tables, des formulaires de saisie, des états de sortie. Ça prenait deux heures à ouvrir sur la machine de l'époque et ça plantait si on avait le malheur d'ouvrir un autre programme en même temps. Mais ça existait. Ça tournait. Et je l'avais fait.

Ensuite, les outils no-code ont commencé à apparaître sérieusement. Softr pour construire des interfaces sans toucher au HTML. Airtable pour remplacer les tableurs complexes par quelque chose de plus lisible. Zapier pour connecter des outils entre eux sans avoir à comprendre ce qu'est une API. Chaque fois, la même logique : un outil qui me donnait accès à une capacité que je n'avais pas techniquement.

J'ai construit des choses avec ces outils. Des vrais choses, pas des jouets. Des outils internes pour des équipes, des processus automatisés qui faisaient gagner des heures par semaine, des tableaux de bord qui remplaçaient des reportings manuels. Rien de révolutionnaire. Des outils qui répondaient à des problèmes réels, construits par quelqu'un qui connaissait les problèmes de l'intérieur parce qu'elle les vivait.

La trajectoire est là, claire, depuis vingt ans. Ce qui a changé, c'est la vitesse. Et une limite qui a bougé.

La limite, toujours la même

Pendant quinze ans, j'ai travaillé dans des directions d'entreprise. COO, CFO, selon les périodes. Des postes où on a des équipes, des budgets, des ressources. Des postes où une idée peut, si elle est bonne et si le timing est juste, devenir un projet, trouver un développeur, obtenir un budget, être mise en production.

Ce que j'avais compris sans me l'avouer clairement, c'est que mes idées dépendaient de cet environnement. Pas seulement pour être financées. Pour exister tout court.

Quand l'environnement portait l'idée, elle avançait. Quand il ne la portait pas, elle attendait. Et « attendre », dans un agenda, ça a un nom : le carnet.

Le mur n'était pas technique. Je savais bricoler. Je savais identifier les bons outils, construire des choses qui tenaient. Le mur, c'était la dépendance. Seule, sans équipe, sans budget, sans le contexte d'une organisation qui donne accès à des ressources, je pouvais faire des petites choses. Mais les idées qui demandaient plus, les idées qui avaient besoin d'un développeur pour la partie que je ne savais pas faire, les idées qui nécessitaient un vrai produit et pas juste un outil interne, celles-là restaient dans le carnet.

Pas par abandon. Par report permanent.

Le carnet

Il existe, dans le tiroir du bas de mon bureau, une pile de carnets plus ou moins pleins, toujours papier blanc non ligné minimum 120g format A5, où j'ai écrit au feutre noir, depuis plus de 20 ans.

Dedans, il y a des feuilles A4 pliées en deux. Des captures d'écran imprimées de problèmes que j'avais observés dans des équipes et pour lesquels je n'avais jamais eu le bon moment.

Il y a une idée d'outil pour aider les équipes commerciales à préparer leurs rendez-vous sans passer une heure à fouiller dans le CRM. Il y a une esquisse d'assistante qui répondrait aux questions des nouveaux arrivants dans une organisation sans qu'ils aient à déranger quelqu'un. Il y a des notes sur la façon dont les équipes RH passent leur temps à répondre aux mêmes questions sur les congés, les notes de frais, les processus internes, et sur ce qu'on pourrait faire pour que cette énergie aille ailleurs.

Ces idées ne sont pas nées dans le vide. Elles sont nées de problèmes réels, observés de près, dans des contextes où j'avais suffisamment de recul pour voir ce qui coinçait. Ce n'est pas de la théorie. C'est de l'observation de terrain accumulée sur vingt ans.

Mais elles sont restées dans les carnets. Parce qu'à chaque fois que j'y revenais, la réponse était la même : pas maintenant. Pas le bon moment. Pas les bonnes ressources. Pas le contexte qui permet de faire ça sérieusement.

Plus tard est une réponse très confortable. Elle ne dit pas non. Elle dit juste : pas encore.

Le problème avec plus tard, c'est qu'il finit par devenir un mode de vie.

La matinée où j'ai repris mes notes

J'ai quitté mon poste et les premières semaines, j'ai fait ce que font probablement tous ceux qui quittent un poste de direction après longtemps : je me suis reposée, j'ai dormi, j'ai relu des livres que j'avais achetés sans les ouvrir. Et puis un matin, sans agenda imposé, sans réunion à préparer, sans urgence qui organisait la journée, je me suis retrouvée assise à mon bureau avec du café et rien d'autre à faire que ce que je voulais faire.

J'ai ouvert le tiroir du bas.

Pas de déclic. Pas de révélation. Juste le fait que plus tard était devenu maintenant, presque par défaut, parce que le contexte qui justifiait l'attente avait disparu.

J'ai sorti les carnets. J'ai relu les notes. Et pour la première fois depuis des années, je n'ai pas pensé « oui mais il faudrait un développeur ». J'ai pensé « voyons ce que Claude peut faire avec ça ».

Ce qui a changé dans l'équation

Je vais être précise, parce que c'est facile de sur-vendre ce moment.

Ce n'est pas que c'est devenu facile. Ce n'est pas que l'IA fait tout à ma place. Ce n'est pas une révolution dans ma façon de penser ou de travailler. La trajectoire est la même depuis vingt ans : j'ai une idée, je cherche comment la faire tenir debout, je bricole.

Ce qui a changé, c'est où se trouve la limite.

Avant, la limite était là : pour transformer une idée en quelque chose qui tourne vraiment, j'avais besoin d'un développeur. Pas pour tout. Mais pour la partie que je ne savais pas faire, la partie qui transforme un prototype no-code en un vrai produit, j'avais besoin de quelqu'un d'autre. Et quelqu'un d'autre, ça veut dire un budget, un contexte, une organisation qui rend ça possible.

Avec Claude, avec Lovable, avec Claude Code, cette limite a bougé. Pas disparu. Bougé. Je peux aller plus loin seule qu'avant. Les parties que je ne savais pas faire, je peux maintenant les faire avec de l'aide, une aide disponible à n'importe quelle heure, qui ne se lasse pas, qui ne juge pas les questions bêtes, qui peut reprendre là où on s'est arrêtées la veille.

Le résultat concret : une idée qui, avant, aurait mis trois mois à devenir un prototype si j'avais trouvé le bon développeur au bon moment avec le bon budget, peut maintenant devenir quelque chose qui tourne en quelques jours. Pas quelque chose de parfait. Quelque chose de réel, qu'on peut tester, qu'on peut montrer, qu'on peut améliorer.

Pour quelqu'un qui avait un tiroir plein d'idées en attente d'un contexte qui ne venait pas, c'est un changement d'équation assez radical.

Ce que ce carnet va être

Je n'écris pas pour les développeurs. Je n'écris pas pour les early adopters de l'IA qui ont déjà tout essayé et qui cherchent le prochain outil.

J'écris pour la financière qui fait ses reportings à la main alors qu'elle pourrait automatiser la moitié. Pour la responsable RH qui répond aux mêmes questions chaque semaine et qui commence à se demander si l'IA pourrait l'aider à récupérer du temps sur ça. Pour la community manager qui gère ses réponses une par une et qui sent que quelque chose pourrait être différent, sans savoir exactement quoi ni par où commencer.

Des gens compétents dans leur métier, qui ne sont pas développeurs et qui ne veulent pas le devenir, mais qui veulent comprendre ce que ces outils peuvent faire pour elles concrètement. Pas en théorie. Pas avec des frameworks. Par les mains.

Ce carnet sera des notes de chantier. Ce que j'essaie, ce qui marche, ce qui casse, ce que j'aurais fait différemment. Des observations sur ce que c'est que de construire des produits avec ces outils, sans équipe, sans budget, sans filet. Des réflexions sur ce que ça change dans la façon de travailler, d'itérer, de décider.

Il y aura des ratés. Il y en a déjà eu. Le prochain projet, celui qui est encore à l'état d'esquisses au crayon, finira probablement par ressembler à autre chose que ce que j'imagine aujourd'hui.

C'est ça, le carnet. Pas la version propre après coup. Les notes pendant.