[🤖] Savoir utiliser activement l’IA rend les possibilités infinies

✨ Résumé de GPT-5.6 Sol 　

Le récit d’une journée où j’ai relié NAS, routeur et HTTPS, corrigé jusqu’à l’interface cassée d’un téléphone réel branché en USB, et ressenti à quel point le domaine que je peux manipuler directement s’élargit avec l’IA.

J’ai regardé les écrans du NAS et du routeur avec Computer Use

Les premières choses auxquelles je me suis heurté aujourd’hui ont été le NAS et le routeur.

Pour rendre le service accessible de l’extérieur, lancer Docker ne suffisait pas. Le domaine devait atteindre le réseau de l’entreprise, le routeur transmettre la requête au NAS, le NAS présenter le certificat, puis le Reverse Proxy l’envoyer au conteneur interne. Autrefois, j’aurais commencé par chercher les manuels tout en passant de l’interface d’administration du routeur à celle du NAS.

Cette fois, je me suis connecté aux écrans d’administration et j’ai approuvé le périmètre des changements, tandis que l’IA regardait les écrans réels avec Computer Use et avançait avec moi.

Un bandeau est apparu au-dessus du navigateur pour indiquer que l’IA avait commencé à le déboguer directement. Je lui ai transmis l’écran tel que je le voyais, et nous avons vérifié ensemble ce qui fonctionnait et où cela bloquait.

Nous avons d’abord contrôlé les réglages existants, laissé intacts le site et les connexions de messagerie qu’il ne fallait pas toucher, puis ajouté uniquement les éléments nécessaires au nouveau service. J’ai envoyé au NAS l’image Docker créée sur mon Mac, je l’ai exécutée dans un environnement Compose séparé, puis j’ai relié le Reverse Proxy et le certificat HTTPS.

La répartition des rôles est devenue encore plus nette ici. Je me suis chargé de la connexion, de la définition de l’objectif, du choix de ce qu’il fallait préserver dans l’environnement existant et de l’approbation des changements réels. Dans les écrans que j’avais ouverts, l’IA a lu les réglages du routeur et du NAS, puis relié plusieurs couches techniques, de Docker et du Reverse Proxy jusqu’au certificat.

L’IA n’a pas modifié les réglages externes à sa guise. J’ai assuré la connexion et l’approbation des changements importants, et nous avons contrôlé le résultat étape par étape tout en conservant un moyen de restaurer l’environnement existant. L’envoi réel de SMS a d’abord été limité à un seul numéro interne approuvé, puis j’en ai confirmé la réception. Une fois la connexion externe terminée, j’ai aussi accédé à l’adresse HTTPS par le réseau mobile du téléphone.

J’ai raconté séparément le transfert des fonctions et données existantes, la vérification d’un SMS limité et le chemin emprunté par une requête externe jusqu’au service dans le NAS dans Migration de l’automatisation historique des congés vers un NAS et connexion HTTPS externe.

Ne pouvait-elle pas regarder directement l’écran du téléphone ?

Arrivé là, j’ai demandé à l’IA :

Tu ne peux pas regarder toi-même l’écran de mon téléphone et le contrôler ? Il n’existe pas un outil pour ça ?

Dans un monde où la virtualisation Android existe, il me semblait étrange que l’IA ne puisse pas voir un téléphone réel connecté en USB. J’ai découvert que adb permettait de lire et de contrôler l’état du téléphone, et que scrcpy pouvait afficher son véritable écran directement sur le Mac.

Après quelques échanges, l’écran de mon téléphone est réellement apparu sur le Mac.

Mon téléphone se trouvait tel quel dans l’écran du Mac, avec même une notification indiquant que Codex travaillait. À partir de là, l’IA ne m’a plus semblé être une simple fenêtre qui répond à des questions. Elle ressemblait à un outil capable de regarder avec moi l’appareil réel que je pouvais voir et toucher.

J’ai corrigé l’interface en regardant le vrai téléphone

scrcpy ne s’est pas arrêté à l’affichage de l’écran du téléphone.

Une fois un téléphone réel avec le débogage USB activé relié au Mac, l’IA pouvait utiliser adb pour capturer l’écran, lire la structure de l’interface, toucher, faire défiler et saisir du texte. Avec scrcpy, je regardais tout le processus en direct. Il ne s’agissait pas de choisir l’un ou l’autre : nous regardions l’écran avec scrcpy, tandis que adb servait aux opérations répétées et à la collecte de preuves.

Sur le moniteur, l’IA lisait l’écran et préparait l’action suivante. Juste devant, le même service était ouvert sur le véritable téléphone.

J’ai ouvert dans Chrome sur le téléphone le service que je développais, je me suis connecté et j’ai parcouru les menus. C’est là que les problèmes invisibles quand je me contentais d’imiter une petite fenêtre de navigateur sur PC ont sauté aux yeux. Sur mobile, la barre latérale occupait presque tout l’écran, tandis que les cartes et les textes étaient écrasés verticalement. Le titre et les boutons de la liste des employés se cassaient caractère par caractère, et il était impossible de comprendre les filtres de l’historique des SMS et de la gestion des congés.

Une seule image avait plus de force qu’une explication du problème. Les caractères de Liste des employés tombaient un à un vers le bas, et seuls des icônes et quelques morceaux de texte restaient dans les filtres. Les défauts que j’avais ratés en réduisant une fenêtre sur PC ne pouvaient plus se cacher sur un véritable écran de la taille d’une paume.

Dans toutes les comparaisons ci-dessous, la gauche montre l’état avant correction et la droite l’état après.

Je ne me suis pas arrêté après la modification. J’ai redéployé l’écran corrigé, je me suis reconnecté sur le même téléphone, j’ai ouvert les menus, fait défiler et vérifié. La liste des employés est devenue lisible horizontalement, et les tableaux larges ont pu défiler autant que nécessaire au lieu d’être comprimés de force.

En regardant l’écran, j’ai donné mes critères : « C’est illisible » et « N’écrase pas le tableau ; il faut pouvoir se déplacer pour le voir ». L’IA a relié ces critères aux modifications réelles de la mise en page et du code. Après le déploiement, juger si le problème était vraiment corrigé est revenu à mes yeux.

Sur les écrans comportant beaucoup de filtres, le problème était encore plus flagrant. La cause était de vouloir entasser tous les champs sur une seule ligne dans la faible largeur mobile. J’ai réorganisé les écrans d’historique des SMS et de gestion des congés autour de deux colonnes, puis placé la plage de dates sur sa propre ligne.

Ces écrans avant-après ne sont pas des captures de données d’exploitation. Après avoir découvert le problème sur le vrai téléphone, j’ai rendu de nouveau l’ancien code et le code corrigé avec les mêmes données synthétiques et la même taille mobile. L’inconfort vu de mes propres yeux a mené à une modification du code, puis est revenu à une vérification sur l’appareil réel.

Cela ressemblait à une fenêtre, mais ce n’était pas une application

Corriger les choses en regardant l’écran du vrai téléphone était déjà fascinant, mais la suite était encore plus drôle.

Je voulais que la fenêtre de scrcpy apparaisse et disparaisse quand j’appuyais sur fn+s dans BetterTouchTool. Toutes les autres applications fonctionnaient bien, mais, sans raison apparente, seul scrcpy ne marchait pas. J’ai capturé l’écran de réglages et l’ai montré à l’IA.

La cause était simple.

Ce que j’avais choisi dans BetterTouchTool n’était pas un paquet d’application macOS ordinaire, mais l’exécutable scrcpy installé par Homebrew. Il ouvre à l’écran une fenêtre qui ressemble à celle d’une application, mais sa nature diffère d’un .app classique attendu par Show / Hide Specific Application de BetterTouchTool. Voilà pourquoi la méthode qui fonctionnait pour les autres applications échouait avec scrcpy.

Ce n’était pas un problème de téléphone. Le raccourci lui-même n’était pas en cause non plus. À mes yeux, cela ressemblait à n’importe quelle autre fenêtre, mais le problème venait de la manière dont le Mac reconnaissait cette fenêtre comme processus et application.

Pour moi, c’était une fenêtre comme celle de toute autre application. L’IA a relié le réglage BetterTouchTool que je lui avais montré au véritable chemin d’exécution et a trouvé pourquoi cette fenêtre seule ne se comportait pas comme une application ordinaire.

Finalement, au lieu d’une action qui affiche ou masque une application classique, je suis passé à un script shell qui trouve directement le processus scrcpy et contrôle son état d’exécution ainsi que l’affichage de sa fenêtre. Le même fn+s fonctionnait désormais comme je le voulais.

À l’instant où j’ai entendu l’explication, je me suis mis à rire.

Waouh… même ça, c’est possible ?

Je n’ai plus besoin de connaître toutes les technologies à l’avance

Autrefois, il y aurait eu beaucoup trop de choses à rechercher à partir d’ici.

Docker et NAS, routeur, DNS, certificats, Reverse Proxy, débogage Android, adb et scrcpy, jusqu’à la façon dont macOS distingue une fenêtre d’une application. Si j’avais tout cherché élément par élément, cela se serait dispersé en problèmes issus de domaines complètement différents.

Pris séparément, aucun de ces sujets n’est peut-être extrêmement difficile. Mais ce ne sont pas des domaines que je maîtrise habituellement en profondeur. Quand je ne sais même pas quoi chercher, un petit problème peut facilement prendre plusieurs heures.

Avec l’IA dans le processus, le déroulement a changé.

J’ai dit quel résultat je voulais. J’ai montré l’écran réel. J’ai montré de nouveau le point qui ne fonctionnait pas. L’IA a relié Docker, le NAS, le routeur, le DNS et HTTPS, mais aussi le téléphone, adb, scrcpy, les fenêtres macOS et les réglages de BetterTouchTool dans un seul flux.

D’un côté, elle regardait le NAS et le navigateur ; dans une autre session, elle creusait le chemin Android et SMS ; dans une autre fenêtre, je contrôlais les résultats. Même lorsque les écrans se séparaient, mon rôle restait identique : fixer l’objectif, approuver jusqu’où changer et juger si le résultat était correct.

Je n’aurais pas ressenti cela si l’IA m’avait seulement fourni beaucoup de connaissances. Ces connaissances sont devenues des commandes de terminal, des gestes sur le téléphone et des réglages d’écrans d’administration, puis elles sont revenues sous la forme d’un changement dans l’écran que j’utilise réellement. Ce n’était pas une réponse. C’était une exécution.

Je n’avais pas étudié toutes ces couches à l’avance. Je n’avais pas non plus tout abandonné en lançant simplement « débrouille-toi ». J’ai continué à regarder les résultats, à pointer ce qui semblait étrange et à poser la question suivante.

J’avais écrit auparavant que la littératie IA est finalement la capacité d’instruire. Aujourd’hui, ces mots m’ont semblé un peu plus concrets.

Instruire ne consistait pas à écrire une impressionnante ligne de prompt. C’était décrire l’état que je voulais, transmettre l’écran sous mes yeux et corriger lorsque le résultat différait. En sachant répéter cela, je pouvais aller bien plus loin que prévu, même dans des domaines que je ne connaissais pas.

L’IA étend la portée de mes mains et de mes yeux

Utiliser l’IA ne m’a pas soudainement rendu expert de toutes les technologies.

Au contraire, en travaillant vraiment avec elle, il arrive sans cesse que l’IA porte un jugement étrange ou aille trop loin dans une direction que je ne voulais pas. Si je ne sais pas ce que je veux ou si je n’ai pas de critère pour juger le résultat, tout le travail de l’IA ne suffira pas à atteindre un bon résultat.

Mais l’inverse est également vrai.

Si je fixe l’objectif, montre l’état réel, repère la mauvaise direction et continue à faire avancer l’IA, tout change. Les choses que j’aurais autrefois laissées de côté en disant « ce n’est pas mon domaine » deviennent des choses que je peux manipuler moi-même. Cela ne s’arrête pas à installer un programme : je peux connecter un appareil réel, voir son écran, vérifier son comportement, le mettre sur un serveur et adapter les parties gênantes à ma manière.

Alors maintenant, au lieu de demander seulement une explication du résultat, lorsque l’écran compte, je dis simplement : « Vérifie toi-même. Avec Computer Use. »

Dans Le changement de paradigme du développement gravé dans les os et la chair, j’avais écrit que le centre du travail du développeur se déplace de la capacité à taper du code vers la planification, la conception, l’exécution et le feedback. Ce que j’ai fait aujourd’hui suivait exactement ce mouvement.

Ce que je voulais réellement créer passait avant la quantité de code que je connaissais par cœur. Ensuite venaient le partage du contexte avec l’IA, la connexion des outils et la correction continue en regardant le résultat.

Aujourd’hui, je l’ai vraiment ressenti.

Si je sais utiliser activement l’IA, je peux faire bien plus de choses que je ne le pensais. Il ne s’agit pas seulement d’obtenir des réponses plus vite. Le champ de ce que je peux voir, toucher et corriger moi-même s’élargit.

Dire que les possibilités sont réellement infinies ne m’a pas semblé exagéré.