L’IA ne remplace pas le métier. Elle le rend visible.

J’ai récemment fabriqué un calculateur de taux d’encrage.

La phrase donne l’impression que je me suis réveillée un matin avec une passion soudaine pour les pixels CMJN et les contraintes réglementaires des emballages.

Ce n’est pas tout à fait ce qui s’est passé.

Je travaillais sur une question très concrète : comment mesurer rapidement la part de surface imprimée d’un emballage, sans envoyer un fichier potentiellement confidentiel vers un service extérieur ? J'avais déjà fait une extension Illustrator, il y a quelques années, mais j'ai eu la flemme de retourner dans la documentation d'Adobe et de devoir le maintenir sur la durée.

Je pouvais chercher un logiciel existant. Je pouvais aussi ouvrir le fichier dans plusieurs outils, effectuer quelques calculs à la main, exporter des visuels et recommencer pour le fichier suivant.

Ou je pouvais essayer de fabriquer l’outil indépendant dont j’avais besoin, dont mes élèves avaient besoin.

J’ai choisi la troisième option.

Pas parce que le monde manquait cruellement d’un nouveau logiciel. Et encore moins parce que j’avais prévu de créer « la plateforme révolutionnaire de l’encrage augmentée par l’IA ».

Je voulais comprendre si je pouvais transformer une tâche précise en un outil simple, accessible gratuitement en ligne.

Le point de départ n’était pas le code

Quand on parle de vibe coding, on montre souvent le résultat.

Une application apparaît à l’écran. Elle possède des boutons, un dégradé plutôt flatteur et parfois même un mode sombre. Tout le monde applaudit. Fin de la démonstration.

Mais le code n’était pas mon premier problème.

Avant de fabriquer le calculateur, il fallait définir ce qu’il devait réellement mesurer.

Une « surface encrée », qu’est-ce que c’est exactement ?

Est-ce la partie du document qui n’est pas blanche ? Comment définit-on le blanc ? Que fait-on d’un fond légèrement gris ? Comment interpréter un fichier PDF contenant plusieurs pages ? Quelle différence faut-il afficher entre la surface imprimée, la couverture moyenne de chaque encre et la charge totale en CMJN ?

Le vocabulaire semblait évident jusqu’au moment où il a fallu l’expliquer à une machine.

Et c’est là que l’expérience est devenue intéressante.

L’IA ne m’a pas seulement aidée à produire du JavaScript. Elle m’a obligée à préciser le problème, à séparer des notions que j’utilisais parfois intuitivement et à décider quelles informations étaient réellement utiles.

Autrement dit, elle a commencé par me demander de faire mon travail de designer.

Décrire une tâche, c’est déjà la redessiner

Le calculateur accepte un PDF, un PNG ou un JPEG. Il analyse le document directement dans le navigateur, mesure la proportion de pixels considérés comme imprimés et affiche une carte visuelle des zones concernées.

Il permet aussi de visualiser des séparations cyan, magenta, jaune et noir, ainsi qu’une estimation de leur couverture moyenne et de la charge d’encre maximale. Un rapport PDF peut ensuite être généré.

Tout se calcule sur l’appareil de la personne qui utilise l’outil. Le fichier n’est pas envoyé vers un serveur. Cette dernière contrainte n’était pas un bonus ajouté à la fin pour écrire « privacy by design » dans une présentation.

Elle faisait partie du problème.

Un fichier d’emballage peut contenir des informations qui ne sont pas encore publiques. Je ne voulais donc pas résoudre une petite friction de travail en créant au passage un nouveau problème de confidentialité.

Chaque choix technique découlait ainsi d’une décision liée à l’usage :

• accepter les formats courants ;
• ne pas transmettre les fichiers ;
• permettre de régler le seuil à partir duquel un blanc est considéré comme imprimé ;
• montrer le résultat plutôt que produire uniquement un chiffre ;
• indiquer clairement ce qui est calculé et ce qui reste estimé ;
• générer un rapport partageable.

Ce n’était plus seulement une liste de fonctionnalités. C’était une manière de formaliser le processus.

Et une fois le processus écrit, je pouvais commencer à le remettre en question.

Ce qui est nouveau, ce n’est pas de fabriquer ses outils

Les professionnels fabriquent leurs propres outils depuis longtemps.

Les macros Excel n’ont pas attendu ChatGPT. Les scripts AppleScript, les actions Photoshop, les plugins, les feuilles de calcul bricolées et les petits programmes internes non plus.

Il y a toujours eu quelqu’un, quelque part, pour transformer un classeur Excel en système d’information critique pour toute une entreprise.

La nouveauté n’est donc pas la possibilité de créer un outil sur mesure.

Ce qui change, c’est le coût d’entrée.

Auparavant, il fallait connaître une syntaxe, comprendre l’architecture d’un programme ou trouver quelqu’un capable de le développer. Aujourd’hui, on peut commencer par décrire son problème en langage naturel, demander une première structure, tester, corriger et avancer par petites étapes.

Cela ne supprime pas la technique.

Cela permet d’entrer dans la technique par le problème plutôt que par le langage.

Je n’ai pas commencé par apprendre tout JavaScript avant d’écrire la première ligne du calculateur. J’ai commencé par expliquer ce que je voulais mesurer, ce que l’utilisateur devait voir et ce qui ne devait jamais quitter son ordinateur.

Puis j’ai progressé en posant des questions. Beaucoup de questions.

Du designer utilisateur au designer d’outils

Cette réflexion ne vient pas uniquement de mon calculateur d’encrage.

Lors d’une conférence organisée chez Laptop, Étienne Mineur présente une pratique dans laquelle le designer ne se contente plus d’utiliser des logiciels existants. Il fabrique de petits outils adaptés à un projet, à une contrainte ou à une manière de travailler.

Ce qui m’intéresse dans sa démarche, ce n’est pas tellement la démonstration technique. Ce n’est pas non plus la promesse de devenir développeuse en trois prompts et deux cafés.

C’est le déplacement du rôle du designer.

Nous avons longtemps conçu des résultats à l’intérieur d’outils pensés par d’autres : une affiche dans Illustrator, une interface dans Figma, une animation dans After Effects. Nous pouvons maintenant commencer à concevoir aussi le processus qui produit ces résultats.

Le designer ne travaille plus seulement avec un outil. Il peut travailler sur l’outil.

La suite de la conférence prolonge cette idée à l’échelle d’une équipe : chacun peut progressivement construire son propre « système d’exploitation » professionnel, composé d’automatisations, d’agents et de petits outils spécialisés.

La vidéo ci-dessous a été l’un des points de départ de mon expérimentation. Je vous conseille moins de regarder les outils présentés comme des recettes à reproduire que d’observer la méthode : partir d’une pratique réelle, identifier une limite, construire une première réponse et conserver son jugement là où il produit de la valeur.

Mon calculateur d’encrage est une expérimentation beaucoup plus modeste. Mais il part de la même question : plutôt que de chercher le logiciel parfait, est-ce que je peux construire une réponse limitée, imparfaite, mais exactement adaptée au problème que je rencontre ?

Ma méthode : réduire avant de construire

La tentation, avec les outils d’IA, est de demander immédiatement beaucoup trop de choses.

Puisque la machine peut ajouter une fonctionnalité, pourquoi ne pas en ajouter douze ? Un espace personnel. Un historique. Une base de données. Des comptes utilisateurs. Une analyse automatique par lot. Un tableau de bord. Une mascotte.

En quelques échanges, le petit outil destiné à résoudre un problème précis commence à ressembler à un logiciel de gestion d’entreprise.

J’ai essayé de faire l’inverse.

Partir d’une seule question

Le premier objectif était simple : quelle proportion du document porte de l’encre ?

Pas : comment gérer toute la conformité d’un emballage ?

Pas : comment remplacer les logiciels de prépresse ?

Pas : comment réinventer l’industrie graphique européenne ?

Une question.

Construire la plus petite réponse utilisable

Il fallait pouvoir déposer un fichier et obtenir un résultat compréhensible.

Le premier prototype n’avait pas besoin d’être complet. Il devait seulement permettre de vérifier si le principe fonctionnait. C’est là que le vibe coding est intéressant : le prototype peut arriver très tôt. On ne passe pas plusieurs jours à spécifier une idée avant de découvrir qu’elle ne répond pas vraiment au problème.

On peut la regarder fonctionner. Ou dysfonctionner, ce qui est souvent encore plus instructif.

Ajouter les contraintes au fur et à mesure

Les fichiers PDF ont introduit la gestion des pages. Les images ont soulevé la question des dimensions physiques, qui ne sont pas toujours disponibles. Le calcul de la surface a rendu nécessaire un seuil de blanc réglable. La visualisation des encres a révélé une différence entre ce que l’on pouvait calculer précisément et ce qu’il fallait présenter comme une estimation.

Chaque nouvelle fonctionnalité répondait à un problème observé, pas à l’envie de remplir une interface.

Montrer les limites dans l’outil

J’aurais pu masquer les approximations derrière un joli pourcentage avec deux décimales. C’est très efficace, les décimales. Elles donnent immédiatement l’impression que quelqu’un sait exactement ce qu’il fait.

Mais le calcul des séparations CMJN possède une limite importante : le document est rendu dans le navigateur, puis les couleurs sont reconstruites à partir du RVB sans profil ICC. Les valeurs par encre sont donc indicatives.

L’interface le précise.

Ce n’est pas très spectaculaire, mais c’est essentiel. Un outil utile ne doit pas seulement produire une réponse. Il doit permettre de comprendre le niveau de confiance que l’on peut lui accorder.

La machine oblige à mettre des mots sur l’intuition

En construisant le calculateur, j’ai dû distinguer plusieurs niveaux de décision.

Certaines règles pouvaient être traduites directement :

• un pixel sous un certain seuil est compté comme encré ;
• une page possède une surface calculable à partir de ses dimensions ;
• une image peut être traitée localement ;
• le rapport doit reprendre les résultats affichés.

D’autres décisions relevaient davantage de mon regard :

• quelles informations placer en premier ;
• comment expliquer la différence entre surface imprimée et taux d’encrage ;
• comment visualiser une zone encrée sans masquer le document ;
• quel avertissement serait assez clair sans transformer la page en notice juridique ;
• à quel moment un détail technique devient inutile pour l’utilisateur.

L’IA pouvait proposer une interface ou une formulation. Elle ne savait pas spontanément ce qui devait être compris en premier. Elle ne connaissait ni le niveau des personnes qui allaient utiliser l’outil ni les erreurs d’interprétation que je voulais éviter.

C’est là que mon métier restait indispensable.

Le modèle pouvait produire. Je devais cadrer, choisir, tester, simplifier et parfois lui expliquer que non, nous n’avions pas besoin d’une animation de confettis après l’analyse d’un fichier.

L’outil reste bancal

Le calculateur fonctionne, mais il ne faut pas lui demander d’être ce qu’il n’est pas.

Ce n’est pas un logiciel professionnel de prépresse. Il ne remplace pas une analyse colorimétrique complète. Les séparations CMJN sont estimées. Les profils colorimétriques ne sont pas conservés dans le calcul. Les grandes images sont réduites pour que l’analyse reste supportable dans un navigateur. Le résultat dépend aussi du seuil choisi pour distinguer le papier blanc des zones imprimées.

Il existe également des cas qui résistent :

• un papier teinté ;
• une image très claire ;
• un vernis ou une encre spéciale ;
• un fichier contenant des tons directs ;
• des transparences complexes ;
• un document dont le fond ne représente pas réellement la surface du support.

Et puis il y a tout ce qui accompagne un outil, même minuscule. Les bibliothèques évoluent. Les navigateurs changent. Un téléchargement fonctionne sur un appareil et se fait bloquer sur un autre. Une personne dépose un fichier auquel je n’avais absolument pas pensé et découvre une erreur très créative.

Fabriquer un outil crée une dette technique. Même lorsqu’il tient dans quelques fichiers.

Les outils génériques ont une valeur réelle

Il serait facile de conclure qu’il faut maintenant reconstruire tous nos logiciels nous-mêmes. Imaginez mon propre Figma.

Ce serait une très mauvaise idée.

Les outils génériques sont parfois frustrants, mais ils possèdent des qualités difficiles à reproduire :

• ils sont maintenus ;
• ils sont documentés ;
• ils utilisent des formats partagés ;
• ils peuvent être transmis à une autre personne ;
• ils ont été testés dans beaucoup plus de situations ;
• ils ne dépendent pas uniquement de la mémoire de leur créatrice.

Un outil personnel peut devenir extrêmement efficace pour une personne et complètement incompréhensible pour toutes les autres. Il peut aussi disparaître dès que le projet change ou que la personne qui l’a créé n’a plus le temps de s’en occuper.

L’interopérabilité n’est pas une contrainte administrative inventée pour nous empêcher de nous amuser. Elle permet au travail de circuler.

La vraie question n’est donc pas : outil générique ou outil sur mesure ?

C’est plutôt : à quel moment la friction justifie-t-elle de construire quelque chose de spécifique, et quel niveau de robustesse cet outil mérite-t-il ?

Mon calculateur n’a pas besoin de devenir une plateforme universelle. Mais s’il doit être utilisé régulièrement par d’autres personnes, il devra être davantage testé, documenté et entretenu.

Le prototype et le produit ne sont pas le même objet.

Le résultat n’est pas seulement le calculateur

Au départ, je voulais gagner du temps et dépasser une limite technique pour créer un petit outil pédagogique sur l'écoconception print. 

À l’arrivée, j’ai surtout obtenu une représentation plus claire du problème. J’ai précisé le vocabulaire. J’ai séparé les données mesurables des estimations. J’ai identifié les exceptions. J’ai réfléchi à la confidentialité des fichiers. J’ai dû décider ce que l’utilisateur devait comprendre avant même de regarder le résultat.

**Le calculateur est donc le résultat visible de l’expérimentation. **Mais le véritable apprentissage se trouve dans le processus qui a permis de le construire. C’est pour cela que la phrase « l’IA remplace les métiers » me paraît souvent trop simple.

Dans cette expérience, l’IA n’a pas remplacé mon expertise. Elle l’a mise sous pression. Elle m’a demandé de l’expliquer. Elle a exposé les endroits où mes décisions étaient précises et ceux où je travaillais encore à l’intuition. Elle m’a donné accès à une compétence technique pour construire seule cet outil plus rapidement. Mais elle n’a pas décidé de ce que l’outil devait être.

Expérimenter avant de vouloir industrialiser

Je pense que nous avons intérêt à fabriquer davantage de petits outils. Pas nécessairement pour les vendre. Pas nécessairement pour les conserver. Et surtout, pas pour ajouter « fondatrice d’une startup IA » à notre biographie LinkedIn. Les fabriquer permet d’examiner notre façon de travailler.

Pour commencer, il suffit de choisir une tâche limitée :

• une friction que l’on rencontre régulièrement ;
• un résultat que l’on sait décrire ;
• un processus que l’on connaît assez bien pour repérer les erreurs ;
• un risque suffisamment faible pour pouvoir se tromper.

Puis construire une première réponse.

La tester.

Observer ce qu’elle ne comprend pas.

Revenir au problème.

Ce mouvement est plus intéressant que la promesse de coder sans coder. Il ressemble finalement beaucoup à une démarche de design classique : comprendre, formaliser, prototyper, tester et recommencer.

La différence est que le prototype peut désormais devenir un véritable outil fonctionnel beaucoup plus rapidement.

Reprendre la main ne signifie pas tout contrôler

Fabriquer ses propres outils ne nous rend pas indépendants de tout. Le calculateur dépend de bibliothèques, de standards web, des capacités du navigateur et du travail de nombreuses personnes que je ne connais pas.

Il n’est pas autonome. Moi non plus.

Mais cette expérimentation m’a permis de reprendre la main sur une petite partie du processus.

Non pas en remplaçant tous les outils existants, mais en construisant une passerelle entre un besoin métier et une possibilité technique.

**Nous avons passé des années à apprendre les logiciels des autres. **Nous pouvons maintenant, plus facilement, tester ce que donnerait un logiciel construit à partir de notre propre manière de travailler.

Le résultat sera parfois utile. Parfois fragile. Parfois franchement inutile.

Mais même lorsqu’il ne devient pas un produit, l’outil peut déjà avoir rempli une fonction essentielle : nous aider à comprendre ce que nous faisons vraiment.