L'IA change le monde

Le premier réflexe : les développeurs

Le monde a changé, il y a peu de temps.

Ce sont d’abord les développeurs qui se sont inquiétés en voyant arriver l’IA, en se demandant si leur métier n’allait pas être remis en question. C’était la question évidente — celle que tout le monde a posée en premier.

Le plafond de verre monte d’un cran : les éditeurs de logiciels

Puis on a vu apparaître sur GitHub une suite graphique entièrement générée par l’IA — l’équivalent de la suite Adobe. Elle existe, elle est publique, et elle s’appelle ArtCraft (storytold/artcraft) :

• 38,9 k étoiles, 6,1 k forks, licence MIT / Apache-2.0, 100 % Rust côté moteur ;
• positionnement assumé : « the IDE for interactive AI image and video creation », « the IDE for artists » ;
• un catalogue de 62 modèles (images, vidéo, musique, maillages 3D, mondes), plus Grok, Midjourney, Sora et World Labs ;
• dans les faits, un socle commun aux applications graphiques de l’organisation : PhotoCraft, LightCraft, VectorCraft, DesignCraft, FilmCraft, EffectCraft, PdfCraft.

Dès lors, la question n’était plus « est-ce que ce sont les développeurs qui sont remis en question ? ». Le plafond de verre était monté d’un cran, et ce sont les éditeurs de logiciels qui sont impactés.

L’argument est économique, et il est brutal :

• qui ira demain payer une licence,
• alors qu’il existe une solution gratuite,
• mise à jour tous les jours,
• développée en Rust — un langage bas niveau, relativement contraignant à écrire,
• ce qui se paie par un maximum de sécurité et un maximum de rapidité.

Et « tous les jours » n’est pas une formule. PhotoCraft a publié 23 versions en 34 jours, dont deux le jour même de sa naissance, avec 16 à 32 binaires par version pour macOS, Windows, Linux, FreeBSD et le web. Un build tous les un à deux jours, dès le premier jour, sans phase de rodage (chiffres du 5 novembre 2026).

La bureautique tombe à son tour

La suite bureautique est ensuite apparue, du même développeur, sur son même compte, avec les mêmes techniques. Elle a un nom par application :

Et le mouvement ne s’arrête pas là — c’est en réalité toute la suite graphique et une partie du métier d’ingénieur qui y passe :

Microsoft a fait sa fortune en grande partie sur Office. Aujourd’hui, Office a été refaite fonction par fonction, gratuitement et publiquement. C’est là que l’histoire ne s’arrête pas : il reste une question à se poser, et elle ne porte plus sur l’éditeur, mais sur notre usage de ces outils.

L’interface n’a plus de valeur

Je n’utilise plus WordCraft au travers de son interface : c’est mon agent IA qui utilise WordCraft à ma place.

Et ce n’est pas une vue de l’esprit : c’est déjà écrit dans le produit. Le README de PhotoCraft annonce une section « Built for agents » :

Every menu item, tool and dialog runs a command from one registry of 500+ commands. The UI, the CLI, the JSON control channel and the MCP server all call the same commands, so anything you can click, a script or an AI agent can do too.

Autrement dit : chaque menu, chaque outil, chaque boîte de dialogue n’est qu’un raccourci vers une commande ; l’interface graphique, la ligne de commande, un canal JSON et un serveur MCP appellent exactement les mêmes commandes. L’application sait déjà être pilotée sans être regardée.

On peut donc légitimement se demander quel est l’intérêt, aujourd’hui, d’un logiciel qui a une interface bien léchée, bien construite, agréable. De ce point de vue : cela n’a plus aucun intérêt.

• La seule interface que nous aurons dans le futur, c’est au pire un terminal, au mieux un micro.
• Savoir que Word a des menus, des fonctions, une ergonomie soignée ne présente plus d’intérêt : dans tous les cas, ce n’est pas nous qui l’utilisons, c’est l’IA.
• Conséquence probable : la prochaine version de l’équivalent de Word ou de PowerPoint ne sera plus qu’un binaire avec une interface spécialisée pour les agents IA. Les projets du compte storytold en prennent le chemin : craft-ai-integrations (« AI layer for the Craft apps »), craft-skills (« corpus of shared skills used in agentic development of craft apps »), craft-common-actions, craft-launcher.

Du connecteur à l’application native IA

Aujourd’hui, les applications ajoutent un serveur MCP pour que les IA puissent s’y connecter. C’est un raccordement : on greffe une prise sur un logiciel conçu pour des mains humaines. Ça fonctionne, mais c’est du provisoire — et c’est bancal, parce que le connecteur expose ce que l’application a bien voulu exposer, avec les trous de son découpage d’origine.

Demain, les applications seront nativement IA : plus de connecteur. Le registre de commandes est le cœur du logiciel, l’interface graphique n’en est qu’une des vues, et le serveur MCP devient une sortie parmi d’autres — au mieux une compatibilité avec l’existant.

PhotoCraft montre exactement cette bascule : ce n’est pas une application avec un MCP ajouté, c’est une application dont chaque menu appelle une commande ; l’UI, la CLI, le canal JSON et le MCP tapent dans le même registre. Le connecteur n’est plus un accessoire greffé sur le produit, il est le produit.

Conséquence : le MCP est une technologie de transition, comme le CMS. Le vrai marqueur n’est pas « mon application a un MCP », c’est « mon application n’a plus besoin d’en avoir un ».

Ce qu’on vérifie n’est plus l’outil, c’est ce qu’il produit

Il faut trancher une fois pour toutes : l’important n’est pas l’outil, c’est la donnée qu’il produit.

Faire une présentation PowerPoint : ce qui compte n’est plus l’ergonomie du logiciel, mais ce qu’il produit. Pour l’humain, au final, le contrôle se résume à trois gestes :

1. projeter la présentation,
2. regarder si elle correspond à ce qu’on voulait,
3. faire corriger en temps réel, en pilotant l’IA à la voix.

Donc la boucle de travail devient :

Le logiciel disparaît entre l’intention et le contrôle. L’interface d’entrée, c’est la voix ; l’interface de sortie, c’est le grand écran — et entre les deux, personne ne regarde les menus. C’est exactement pour cela que l’ergonomie ne vaut plus rien : elle était l’interface, elle n’est plus que le milieu d’une chaîne que l’humain ne traverse plus.

Ce qui remplace l’interface n’est pas la donnée, c’est le contexte

La distinction tient en une ligne : « les données indiquent aux agents ce qui existe, tandis que le contexte leur indique ce qui compte ».

Le contexte, ce sont les politiques, les autorisations, les priorités, les échéances, les relations entre systèmes, la provenance. Un agent peut très bien récupérer la bonne information et prendre la mauvaise décision : le document est à jour, mais hors du périmètre de l’utilisateur, ou contraire au gel de dépenses décidé la veille. Ce qui manque n’est pas la donnée, c’est le cadre.

Et ce cadre a trois noms, qui sont exactement ceux du contrôle : la gouvernance (ce que l’agent peut savoir et faire, et quand un humain doit reprendre la main), la provenance (d’où vient l’information, est-elle à jour, fait-elle autorité), l’observabilité (ce qu’il a consulté, comment il a décidé, ce qu’il a fait). Une seule façon de les tenir : les installer avant l’action, pas les constater après.

Autrement dit : on ne remplace pas une interface par une meilleure interface, ni par plus de données. On la remplace par ce que l’agent doit savoir pour avoir le droit d’agir.

Deux conséquences :

• le livrable doit rester ouvert et vérifiable : un fichier (PDF, PPTX, PSD, PNG, un diff Git) qu’on peut projeter, comparer, archiver — pas un état interne à une application ;
• la valeur se déplace vers la relecture : le temps gagné sur la fabrication se réinvestit dans le contrôle du résultat, pas dans l’apprentissage de l’outil.

Les CMS n’ont plus de raison d’être

Il existe aujourd’hui plein de CMS. Ils sont régulièrement attaqués, on y retrouve pas mal de failles de sécurité et, pour compléter le tout, on y ajoute une multitude de plugins — qui apportent eux aussi de l’insécurité, parce que souvent mal contrôlés et remplis de failles.

Alors, quel intérêt d’utiliser ce type de CMS aujourd’hui ?

• On l’utilisait parce que c’étaient des humains qui géraient : on avait besoin d’une interface simple et agréable pour mettre à jour son site.
• Certains le pilotent déjà autrement ; le CMS est une infrastructure legacy avec ses liens et ses dépendances, mais ce n’est pas la finalité.
• La finalité, c’est que ce soit directement l’IA qui gère votre site : on lui donne des instructions, des photos, des modèles, des idées — et la mise à jour se fait via l’agent, et non plus au travers d’un CMS qui va fournir un site.

L’infrastructure : le cas vCenter et VMM

La même démonstration vaut pour l’infrastructure.

J’ai fait la démonstration avec des instructions absolument simples : déployer une machine virtuelle avec une application à l’intérieur, et obtenir dans la même foulée :

Du plan sur le papier au déploiement par l’agent

L’infrastructure c’est mon métier, et c’est là que la bascule est la plus nette — parce que l’ordre des choses s’inverse.

Hier : on montait l’infrastructure, puis on improvisait la documentation. Le document d’architecture technique, les cahiers d’exploitation, les procédures : écrits après coup, une fois que tout marchait, de mémoire, par celui qui savait déjà comment ça marchait — et périmés dès la première évolution.

Demain : on écrit tout d’abord. Comment ça va être géré, cloisonné, sauvegardé, supervisé, repris après sinistre. Ce document n’est plus le compte rendu du travail : il est le travail. Et c’est ce texte qu’on donne à l’agent, chargé de le mettre en œuvre.

Corollaire à retenir : une documentation qui n’est pas écrite avant ne sera jamais à jour après. Ce n’est pas une question de discipline, c’est une question d’ordre des opérations.

Demain, ce plan se construit à deux, avec l’IA, sous la forme d’un véritable cahier des charges : tout ce qu’on veut, décidé et écrit avant de toucher au premier équipement.

Quand le design est validé, on le confirme à l’IA — en lui donnant les informations de connexion aux périphériques physiques (pare-feu, commutateurs, hyperviseurs) — et elle fait entièrement le déploiement. Le document lui est remis comme une charge : il ne l’interprète pas, il l’applique.

Ce que ça déplace :

• le métier passe de l’exécution à la conception et à la validation. Comme pour le reste : intention, production, contrôle. L’ingénieur ne configure plus, il arbitre et il vérifie ;
• le cahier des charges devient exécutable. Un plan lu par un humain supportait l’approximation (« on verra sur place ») ; un plan lu par un agent ne la supporte pas. Il doit être non ambigu, versionné, rejouable et idempotent ;
• l’agent entre lui-même dans les cercles de confiance. C’est le point délicat : celui qui déploie détient les accès. Un design sérieux doit dire quels droits on lui donne, sur quoi, pour combien de temps, et comment on les lui retire. Le plan de sécurité doit inclure l’outil qui applique le plan de sécurité ;
• l’humain garde ce qui n’est pas délégable : le niveau de PRA accepté, le cloisonnement choisi, les accès physiques, et le feu vert.

Et une ironie utile : l’infrastructure fait ça depuis toujours — on conçoit avant de câbler, on documente avant d’exploiter. Ce que le monde du développement découvre avec le « gate amont » (décider l’intention avant le code), l’ingénieur système l’applique depuis trente ans. La différence, c’est que le plan ne sera plus seulement lu : il sera exécuté.

L’industrie du logiciel : la valeur passe au contrôle

Ce n’est pas une affaire de web. Une application, un site, un service, un pilote, un firmware : tout passe par la même chaîne, donc tout subit la même bascule. C’est là que le raisonnement se referme.

Jusqu’ici, on s’est contenté de faire écrire du code par une IA. C’est la moitié du métier : personne ne valide. Or la production vient de devenir gratuite et continue — 23 versions en 34 jours chez PhotoCraft. Aucune équipe ne peut qualifier à ce rythme avec des moyens humains. Le goulot n’est plus d’écrire, il est de garantir.

La même bascule est déjà écrite ailleurs : « lorsque le réseau est saturé, le travail autonome redevient du travail humain ». La phrase dit tout. Un agent qui produit plus vite qu’on ne sait contrôler ne gagne rien : il remplit une file d’attente. Le goulot ne se supprime pas, il se déplace — et il finit toujours par se poser là où un humain doit encore regarder.

D’où le déplacement, et c’est le cœur du sujet : la valeur ajoutée d’un projet logiciel passe aux tests et aux contrôles. Pas des tests écrits à la main, en retard, à moitié, quand il reste du temps. L’humain doit construire avec l’IA l’outil de qualification ultime — celui qui couvre les fonctions, les accès, la concurrence, les cas tordus, les performances, les régressions — et qui se déclenche à la moindre mise à jour.

C’est un renversement de statut. Le test était la tâche ingrate qu’on rognait quand le planning serrait ; il devient le code le plus précieux du projet. Trois raisons :

• c’est le seul code qui ne peut pas être générique. Une IA écrit n’importe quelle fonction ; elle n’écrit pas « ce que ce produit-là ne doit jamais redevenir ». L’outil de qualification est fait de l’histoire du produit : chaque défaut qui a passé une fois devient un test qui ne repassera pas ;
• il porte la mémoire. Les développeurs passent, les agents se remplacent, le harnais de test reste. C’est lui qui sait pourquoi ce contournement existe, quelle limite a été acceptée, quel cas client a déjà cassé la facturation ;
• il fixe le rythme. C’est parce qu’il existe qu’on peut publier tous les jours. Sans lui, la vitesse de production devient une dette ; avec lui, elle devient un avantage.

Un partage simple : le surhumain à la machine, l’humain aux humains

« Exhaustif » ne veut pas dire parfait : cela veut dire que rien ne sort du périmètre du contrôle. Ce qui n’est pas testé n’est pas livrable.

Et il faut le dire franchement : ce genre de test n’est pas un travail pour des humains. Rejouer la qualification complète à chaque mise à jour, sur des milliers de cas, sans fatigue et sans oubli : aucune équipe ne tient ce rythme, et personne ne devrait essayer. Ce n’est pas une question de courage ni de rigueur — c’est au-delà de ce qu’un humain peut faire. C’est une tâche surhumaine, au sens propre du terme.

D’où le partage, qui est le fond de tout ce texte :

Ce n’est pas une hiérarchie, c’est une répartition — et les deux erreurs coûtent cher :

• demander à des humains de faire le travail de la machine donne des tests partiels, en retard, et une fausse assurance : on croit contrôler parce que quelqu’un a relu ;
• demander à la machine de décider ce qui doit être vrai donne un contrôle qui valide n’importe quoi avec beaucoup d’aplomb.

Concevoir le harnais se fait à deux, l’humain et l’IA. Le faire tourner, non : c’est la machine. Et c’est précisément pour ça qu’on peut publier tous les jours.

Et le bénéfice n’est pas seulement mécanique. Déchargé de ce qui est hors de portée humaine, l’esprit n’est plus mobilisé pour vérifier l’invérifiable : il l’est pour créer et pour juger. Cela libère la créativité et l’esprit critique — et ce qui était impossible hier devient possible aujourd’hui. Ce n’est pas une promesse : c’est la conséquence directe du partage. Une équipe qui passe ses journées à rejouer des tests à la main n’a plus de cerveau disponible pour se demander si le produit est le bon.

En face de l’outil de qualification, des agents sont conçus pour le développement de l’application : leur travail n’est pas de trouver des problèmes, il est de résoudre les issues. Chacun son rôle — et surtout, celui qui fabrique n’est pas celui qui juge.

BUILD
  les agents de développement lisent les issues et les résolvent
  ->  code, version déployée

CONTRÔLE
  le harnais de qualification rejoue tout, à chaque mise à jour :
  fonctions, accès, concurrence, performances, régressions
  ->  issues ouvertes dans le dépôt Git, retour au build

Tant qu’il reste une issue ouverte, l’application n’est pas sortie. Le critère de sortie, c’est le silence du contrôle : plus aucune anomalie ouverte, l’appli sort du workflow.

Limite de la boucle : elle corrige des défauts, elle ne rattrape pas une intention mal décidée. Ce qui se joue en amont ne se répare pas en aval à la vitesse de l’IA.

Ce que ça change :

• L’issue est le contrat entre les deux parties. Lisible, datée, traçable, elle survit à l’agent qui l’a écrite et à celui qui la ferme. C’est aussi la réponse à la question de la responsabilité : la trace n’est ni le fil de discussion ni la mémoire d’un modèle — c’est l’issue, le commit et le test qui la ferme.
• Le contrôle porte sur le résultat, pas sur le code. Comme on projette la présentation au lieu de relire les diapositives, on valide l’application en fonctionnement — pas l’élégance de l’implémentation.
• La qualité devient une propriété du processus, pas de la vigilance humaine : elle tient au fait qu’il existe un juge, pas à ce que quelqu’un ait bien relu.
• Le métier qui monte est celui du contrôle — mais pas en l’exerçant à la main. Écrire le critère, décider ce qui doit être vrai après chaque mise à jour, arbitrer ce qu’on accepte de laisser passer : c’est là que passe le travail humain. L’exécution, elle, est déjà du côté de la machine.

Le compte storytold en montre déjà la mécanique visible : SonarCloud sur chaque projet, revue automatique des pull requests par CodeRabbit, un outil maison de suivi des PR et des builds (craft-repo-status-app), et un corpus de skills partagées pour le développement agentique (craft-skills). Ce n’est plus un pari : c’est une chaîne qui tourne.

Et c’est là que tout se referme. Le logiciel n’a plus besoin d’interface parce que l’agent s’en occupe ; le site n’a plus besoin de CMS parce que l’agent le gère ; la machine virtuelle n’a plus besoin de vCenter parce que la commande suffit. Reste une seule chose à construire : l’usine — d’un côté ce qui fabrique, de l’autre ce qui contrôle, et une porte de sortie qui ne s’ouvre que quand le contrôle se taît. Et dans cette usine, la partie qui vaut de l’argent n’est pas celle qui produit : c’est celle qui qualifie, parce que c’est la seule qu’on ne peut pas acheter prête à l’emploi.

Où passe le style du développeur : le skill et le modèle

Si le code est écrit par des agents et validé par des agents, la question qui tue devient : qu’est-ce qui distingue encore deux développeurs ? Ce n’est plus la vitesse de frappe, ni la connaissance du framework, ni le nombre d’années sur le même CMS. C’est la consigne.

Le style passe alors dans deux leviers, et deux seulement :

Le skill, c’est le goût devenu livrable. Un fichier, versionné avec le projet, réutilisable d’un site à l’autre, copiable, transmissible, vendable. Le style cesse d’être un secret de main-d’œuvre : il devient un actif. Et il devient vérifiable — un agent de contrôle peut tester que le rendu respecte le skill, donc le style entre dans le critère de sortie de l’usine logicielle.

Il installe pourtant un plancher, pas un plafond : au-dessus du skill, il y a le modèle ajusté sur ses propres choix.

Le modèle, c’est la pellicule. Chaque moteur a un « taste » : une manière de choisir un espacement, une teinte, une formulation, quand on ne lui dit pas. Ce n’est pas décoratif, c’est mesurable — j’ai des tests là-dessus, sur la même consigne passée à plusieurs modèles. Le développeur de demain choisit son moteur comme un photographe choisit sa pellicule : pour la couleur qu’elle donne, pas pour sa vitesse. Et ce n’est pas de la magie : un modèle tend vers la médiane statistique de ce qu’il a appris — ce que SFEIR appelle la « convergence distributionnelle » — avec parfois un simple biais de position qui se déguise en goût.

Conséquences :

• le style est comparable : un banc d’essai — un brief, un skill, N modèles — et l’on garde ce qui ressemble à ce qu’on veut produire ;
• le style se délègue sans se perdre, à condition d’être écrit : ce qui n’est pas dans le skill n’existe pas, et c’est le goût moyen du modèle qui s’installe à la place ;
• le métier se déplace : le travail du senior n’est plus d’écrire le code, il est d’écrire la consigne, de choisir le moteur, et de juger le rendu — les trois gestes de la boucle de contrôle ;
• c’est déjà notre pratique : la bibliothèque de skills du référentiel interne n’est pas de la documentation, ce sont des actifs de style.

Demain, un développeur se reconnaîtra à son SKILL.md et à la liste de modèles qu’il a choisis — pas à son éditeur de code.