L’évolution de l’automatisation : des scripts shell aux organisations d’IA

La technologie change, mais le marché de base reste le même : investir une fois pour ne pas refaire éternellement le même travail.

Je construis des logiciels depuis longtemps, et une chose à propos de l'automatisation est restée remarquablement constante pendant tout ce temps : la technologie change, mais la logique non. Si je me surprends à faire la même chose de façon répétée, il arrive presque toujours un moment où il devient rentable d'investir du temps en amont pour l'automatiser.

À la fin des années 1900, cela pouvait vouloir dire écrire un script shell. S'il fallait renommer un tas de fichiers, traiter des données de manière reproductible, copier des choses entre systèmes ou lancer sans cesse les mêmes commandes, je pouvais soit continuer à le faire à la main, soit prendre le temps de l'écrire une bonne fois. Créer le script prenait parfois plus de temps que d'exécuter la tâche une seule fois, mais là n'était jamais la question. Le gain venait de chaque répétition suivante.

Cette équation de base n'a pas changé. Ce qui a changé, c'est l'échelle de ce que nous sommes capables d'automatiser.

D'abord, nous avons automatisé des tâches

Les premières formes d'automatisation avec lesquelles j'ai travaillé étaient petites et locales. Un script shell remplaçait une série de commandes. Une tâche cron déclenchait quelque chose selon un calendrier. Un script Perl ou Python transformait un flux répétitif en quelque chose de reproductible.

Les exemples typiques ressemblaient à ceci :

• Renommer ou déplacer de gros lots de fichiers
• Traiter les données de la même manière à chaque fois
• Copier des fichiers entre systèmes
• Exécuter des commandes de déploiement répétitives
• Planifier des travaux de maintenance récurrents

L'abstraction était simple : je sais exactement ce que je veux que la machine fasse, je peux le décrire assez précisément, et je préfère passer du temps à le lui apprendre une fois plutôt que de continuer à le faire moi-même indéfiniment. Cela signifiait parfois passer deux heures à automatiser une tâche qui ne prenait que cinq minutes à la main, ce qui paraît ridicule si vous ne comptez la faire qu'une fois. Si vous comptez la faire des centaines ou des milliers de fois, cela devient évident.

Ce même schéma s'est répété à mesure que les systèmes logiciels se compliquaient.

Ensuite, nous avons automatisé l'infrastructure

Le cloud a élargi le champ de ce qui pouvait être scripté. Au lieu d'automatiser une tâche sur une machine, nous avons commencé à automatiser la création et la configuration des machines elles-mêmes.

Terraform nous a permis de décrire l'infrastructure sous forme de code. Kubernetes nous a permis de décrire comment des applications distribuées devaient s'exécuter, monter en charge, redémarrer et communiquer. Les systèmes de CI/CD ont automatisé le passage du logiciel du gestionnaire de versions à la production.

Soudain, des choses qui exigeaient traditionnellement un travail opérationnel manuel considérable pouvaient être déclarées puis recréées :

• Serveurs
• Réseaux
• Bases de données
• Répartiteurs de charge
• Permissions
• Déploiements d'applications
• Règles de mise à l’échelle
• Environnements entiers

Ce qui impliquait autrefois des gens cliquant dans des consoles, configurant des systèmes à la main et coordonnant des déploiements est devenu peu à peu quelque chose que l'on pouvait versionner, relire, tester et reproduire.

Le coût initial a grossi parce que l'objet automatisé a grossi. Une bonne automatisation d'infrastructure est plus difficile qu'un script shell de dix lignes. Elle demande plus de réflexion, plus de cas limites, plus de débogage et plus de maintenance. Le gain, lui, croît au même rythme que la complexité. Une fois un environnement correctement défini, des systèmes entiers qui exigeaient des heures ou des jours d'installation manuelle se recréent avec très peu d'effort humain.

Le principe de l'automatisation est resté exactement le même. Nous avons simplement monté d'un cran.

Aujourd’hui, nous automatisons des flux de travail

Les agents IA repoussent cette abstraction encore d'un cran. Au début, l'usage évident consistait à traiter un agent comme un script très compétent : lui confier une tâche, le laisser l'exécuter et récupérer le résultat.

C'est utile, mais c'est aussi une façon assez étroite de comprendre ce qui se passe. Le vrai basculement, c'est que nous pouvons désormais automatiser non plus seulement des tâches isolées, mais la coordination de tâches entre plusieurs travailleurs intelligents.

Un flux de travail agentique moderne pourrait ressembler à ceci :

• Un agent écrit le code.
• Un autre relit l'implémentation.
• Un autre exécute les tests.
• Un autre traque les problèmes de sécurité.
• Un autre vérifie que les exigences initiales ont bien été satisfaites.
• Un flux décide de ce qui se passe en cas d'échec.
• Des points de validation déterminent ce qui requiert un humain et ce qui peut avancer automatiquement.

À ce stade, vous ne scriptez plus le travail. Vous scriptez le système qui organise le travail. C'est un saut bien plus grand que de remplacer une tâche manuelle par une tâche IA. La frontière de l'automatisation se déplace de l'exécution vers la coordination.

Orgabot est la dernière version de la même idée

C'est ainsi que je vois Orgabot. Il est facile de considérer l'orchestration d'agents IA comme quelque chose de fondamentalement différent des outils d'automatisation qui l'ont précédée, mais sur le plan abstrait c'est le même schéma que j'utilise depuis des décennies.

La progression est assez limpide :

• Un script shell automatisait des commandes que je ne voulais pas retaper sans cesse.
• L'infrastructure-as-code automatisait des systèmes que je ne voulais pas reconfigurer sans cesse.
• La CI/CD automatisait des flux de déploiement que je ne voulais pas coordonner à la main.
• L'orchestration d'agents automatise un travail que je ne veux pas piloter étape par étape.
• Orgabot pousse cela vers l'automatisation de la structure qui entoure les travailleurs eux-mêmes.

La différence est l'échelle. Avec un outil comme Orgabot, l'objet automatisé n'est plus une commande ni même un pipeline de déploiement. Ce peut être un processus complet de développement logiciel, avec plusieurs agents spécialisés, des permissions, des points de relecture, des étapes de vérification et une logique de déploiement.

Le passage se fait du scriptage d'une tâche du type « construis cette fonctionnalité » vers la définition d'un système capable de décider, encore et encore, comment les fonctionnalités doivent être construites, par qui, comment le travail doit être relu et quand il est prêt à partir. Cela commence à ressembler moins à l'automatisation d'un développeur qu'à l'automatisation de pans entiers d'une organisation.

L'automatisation ne cesse de monter dans la pile d'abstractions

Avec le recul, la progression est remarquablement cohérente :

• Nous avons automatisé des commandes.
• Puis des tâches répétitives.
• Puis des déploiements.
• Puis l'infrastructure.
• Puis des pipelines et des flux de travail.
• Aujourd’hui, nous automatisons les travailleurs à l’intérieur de ces flux.
• Et de plus en plus, la coordination entre ces travailleurs.

Chaque étape déplace la frontière vers le haut. Ce qui est intéressant, c'est que chaque étape donne l'impression d'être le sommet. Quand l'infrastructure est devenue programmable, cela a semblé un bond d'abstraction énorme. Quand les agents IA se sont mis à écrire du logiciel, il était facile d'imaginer que nous avions atteint le point d'arrivée naturel : dire à l'IA ce que l'on veut et la laisser le construire.

Mais même cela commence déjà à ressembler à une étape intermédiaire. Plutôt que de dire à un agent quoi faire, nous construisons des systèmes qui décident quels agents doivent travailler, comment ils doivent collaborer, comment leur travail doit être évalué et ce qui doit se passer ensuite. D'où la question évidente : qu'y a-t-il au-dessus de l'orchestration automatisée ?

Que pourra-t-on scripter dans dix ans ?

Si le schéma se poursuit, la prochaine abstraction pourrait être bien plus vaste que tout ce que nous appelons aujourd'hui un flux de travail. Peut-être que l'unité automatisée deviendra une organisation entière.

Vous pourriez décrire un objectif commercial et laisser un système assembler les équivalents de :

• Développement produit
• Ingénierie
• Infrastructure
• Marketing
• Support client
• Finance
• Processus juridiques
• Analytique
• Opérations

L'entrée deviendra peut-être moins procédurale et plus intentionnelle. Au lieu de spécifier des tâches, des flux ou des agents, vous exprimeriez simplement un objectif du type « je pense qu'il devrait exister un produit qui fait ceci », et le système déterminerait tout ce qu'il faut pour rendre cette idée réelle.

Il y a là un schéma historique plus large. L'interaction entre l'humain et la machine ne cesse de monter vers des niveaux d'intention plus élevés :

• Le code machine est devenu des langages de programmation.
• Les langages de programmation se sont dotés de bibliothèques et de frameworks.
• Les serveurs sont devenus des déclarations d'infrastructure.
• Les commandes sont devenues des prompts.
• Les prompts deviennent des objectifs.

L'aboutissement logique, c'est que nous passions moins de temps à décrire comment quelque chose doit se produire et davantage à décrire ce que nous voulons voir exister. Peut-être que dans dix ans, l'idée même d'orchestrer explicitement des agents paraîtra primitive. Peut-être exprimerons-nous simplement une intention en laissant un système bâtir en dessous la combinaison d'agents, d'outils, de flux, d'infrastructures, d'organisations et de processus nécessaire.

À l'extrême, l'interface pourrait tenir moins de la programmation que de la manifestation : penser quelque chose, le décrire, et regarder un système automatisé transformer cette intention en réalité. Cela paraît spectaculaire, mais chaque couche d'abstraction précédente aurait paru spectaculaire avant d'exister.

L'économie de l'automatisation n'a jamais vraiment changé

Ce que je trouve le plus intéressant, c'est que malgré tous ces progrès, le marché reste presque identique à celui que je passais en écrivant des scripts shell il y a des décennies. L'automatisation exige toujours un investissement initial. Il faut définir le processus, construire le système, gérer les cas limites, déboguer les échecs et décider de ce qui doit se passer quand la réalité ne correspond pas à vos hypothèses.

Le travail manuel paraît souvent plus simple au départ, précisément parce qu'il évite cet investissement. Puis l'automatisation se met à tourner, les répétitions s'accumulent et le gain devient évident.

C'était vrai quand l'automatisation tenait en dix lignes de shell. C'était vrai quand elle est devenue des milliers de lignes de configuration d'infrastructure. C'est vrai aujourd'hui, alors que nous commençons à orchestrer des équipes d'agents IA. L'échelle ne cesse d'augmenter, mais le principe n'a presque pas bougé : fournir l'effort une fois pour ne pas avoir à le fournir toujours.

Et si le schéma se poursuit, la question la plus intéressante n'est pas ce que nous pouvons automatiser aujourd'hui. C'est ce qui semblera encore trop grand pour être automatisé demain.