J’ai des compétences limitées en code. Et pourtant, j’ai construit une extension Chrome qui fonctionne : elle capture le texte d’un post LinkedIn, en récupère l’image, demande à une IA d’en faire un résumé, et envoie tout ça dans mes notes. Pour ça, j’ai utilisé deux outils, Antigravity pour écrire le code et Gemini pour m’accompagner en amont dans la réflexion.
Je suis contente du résultat technique : cette première version va déjà me faire gagner du temps. Mais ce qui m’a le plus marquée, c’est autre chose. La compétence qui a fait la différence, ce n’était pas une compétence technique. C’était ma capacité à poser des questions, à cadrer, à consulter plusieurs points de vue avant d’agir. La clé, c’était une compétence managériale. Celle que je mobilise quand j’accompagne un changement en entreprise. Celle que vous mobilisez quand vous managez une équipe dans une vraie démarche d’amélioration continue.
Bien définir le besoin avant d’agir
Je suis partie d’une idée encore floue : je voulais une extension pour capturer des pages web, avec de l’image, du texte, une IA quelque part dans le processus. Rien de plus précis. J’ai utilisé l’interface vocale de Gemini pour lui parler directement, sans construire mes phrases à l’avance, presque comme si je réfléchissais à voix haute. J’ai aussi dit à Gemini que ça méritait des questions.
Gemini m’en a posé quatre : est-ce que je voulais capturer l’écran entier ou une sélection, est-ce que je voulais que l’IA analyse toute la page ou seulement ce que j’aurais choisi, quel modèle d’IA j’avais en tête, et où je voulais que les données atterrissent. Mes réponses, encore approximatives à ce stade, ont permis une reformulation plus précise. Et cette reformulation a fait apparaître un point que je n’avais pas anticipé : mon idée initiale, capture d’écran plus reconnaissance visuelle du texte, était en fait plus complexe et plus fragile que nécessaire pour ce que je voulais vraiment faire avec les posts LinkedIn.
Au lieu de foncer sur l’idée de départ, j’ai accepté de démarrer avec une version plus simple, pour la tester d’abord, avant d’envisager la suite. En conduite de changement, je retrouve exactement ce mouvement. La première formulation d’un problème par une équipe est presque toujours partielle, parfois même à côté du vrai sujet. Le temps passé à la questionner, à la reformuler avec elle, n’est pas du temps perdu. C’est souvent ce qui évite de construire une solution robuste pour un problème qui n’était pas le bon.
Recenser les parties prenantes, se mettre à leur place
Avant de coder quoi que ce soit, j’ai également demandé à Gemini de se mettre à la place de plusieurs métiers différents. D’abord un spécialiste de l’expérience utilisateur : qu’est-ce qui pourrait rendre l’outil pénible à utiliser au quotidien, si je clique et qu’il ne se passe rien pendant trois secondes, par exemple. Ensuite un responsable sécurité : où se trouvent les risques si une clé d’accès à l’IA traîne en clair dans le code, ou si des données confidentielles partent vers un service extérieur sans que je le sache. Puis j’ai demandé s’il fallait consulter d’autres experts, et Gemini m’a proposé un product owner pour découper le projet en étapes digestes, un testeur pour anticiper ce qui casse en usage réel, et un architecte système pour vérifier que l’environnement de travail était prêt.
Chacun de ces points de vue a fait remonter quelque chose que je n’aurais pas vu seule. Le testeur, par exemple, a pensé aux caractères accentués dans les titres de fichiers, un détail technique en apparence, mais qui a fini par provoquer de vrais bugs plus tard. Le responsable sécurité a posé une règle simple qui a structuré tout le reste du projet : une clé d’accès ne doit jamais rester écrite en dur dans le code.
Cette manière de convoquer plusieurs regards avant d’agir n’a rien de spécifique à l’informatique. C’est ce que fait un bon comité de pilotage (ou de direction), ou un atelier qui réunit plusieurs métiers autour d’un même projet, à condition que les postures soient vraiment différentes les unes des autres, et pas de simples variations d’un même point de vue.
Demander à l’IA de questionner plutôt que de répondre
Il y a un moment particulier dans cette expérience où j’ai changé la nature de ma demande. Plutôt que de demander une solution, j’ai demandé : y a-t-il un autre spécialiste dont je devrais solliciter l’avis avant de commencer ? J’aurais aussi pu dire à Gemini « Je n’aime pas trop [tel ou tel aspect], mais je ne sais pas quoi changer. Propose-moi trois pistes d’amélioration, avec les points forts et faibles de chacune, afin que je puisse faire mon choix. »
Ce ne sont pas des questions techniques. Ce sont des questions qui visent à élargir le champ, à faire apparaître un angle mort avant qu’il ne devienne un problème.
Ce déplacement, utiliser l’IA pour interroger plutôt que pour exécuter, ressemble beaucoup à ce qu’un bon manager cherche à faire avec son équipe. Disposer d’une solution a un effet rassurant à court terme, mais ça prive l’équipe, ou ici moi-même, de l’occasion de voir le problème sous un autre angle. Poser la question inverse, demander à être questionnée, demande un peu plus de temps, mais élargit vraiment la réflexion avant d’agir.
Ce que l’IA a augmenté, ce n’est pas la vitesse
Le projet a été découpé en quatre étapes, chacune testée avant de passer à la suivante : d’abord une simple liaison technique, puis la capture du contenu d’une page, puis la connexion à l’IA pour le résumé, puis la sécurisation des réglages. Chaque étape avait des consignes précises : le rôle attendu, le contexte, l’objectif, les spécifications, et ce qui devait être livré.
Ça n’a pas été linéaire. Il y a eu des erreurs qui sont revenues plusieurs fois, notamment sur la connexion à l’IA de résumé, qui a échoué à trois reprises avant de fonctionner. Et le vrai déblocage n’est pas venu d’une nouvelle tentative technique, mais d’une relecture attentive du code produit : j’ai repéré une valeur dupliquée à deux endroits différents, qui masquait silencieusement l’erreur réelle plutôt que de la signaler. Ce que j’en retiens, c’est que l’IA peut corriger un symptôme sans en questionner la cohérence d’ensemble, si personne ne le lui demande.
C’est là, je crois, ce que l’IA a vraiment augmenté dans ce projet. Pas la vitesse d’exécution. La qualité du cadrage en amont, et la nécessité de rester en veille sur ce qu’elle produit plutôt que de l’accepter telle quelle. Sans ce cadrage, sans ce découpage en étapes vérifiables, le projet n’aurait probablement pas abouti, ou aurait produit quelque chose de bancal.
Cette façon de travailler, humaine au cadrage et à la validation, IA à l’exécution et parfois au questionnement, ressemble beaucoup à ce qu’une bonne conduite de changement a toujours cherché à faire. Le détail technique des prompts et du code est sur l’article complémentaire, Créer une extension Chrome avec Antigravity, pour ceux qui veulent creuser cette partie-là.
Et vous, avez-vous déjà mené un projet avec l’IA où le plus difficile n’était pas technique ? Je suis curieuse de lire vos expériences en commentaire.
Pour aller plus loin