Rendre les logiciels d’une PME pilotables par des agents IA

L'essentiel à retenir

Faire travailler un agent IA dans un logiciel ne devrait pas consister à lui demander de cliquer au hasard jusqu’à obtenir le bon écran. Pour une PME belge de 10 à 50 personnes, l’approche la plus saine consiste à lui fournir une surface d’action explicite : des commandes documentées, des entrées structurées, des sorties contrôlables et des droits limités.

CLI-Anything explore cette direction. Ce projet open source génère des interfaces en ligne de commande pour piloter de vrais logiciels, notamment GIMP, Blender, LibreOffice, Audacity et QGIS. L’agent n’imite plus seulement un utilisateur devant une interface graphique. Il appelle des opérations définies et peut recevoir un résultat lisible ou structuré en JSON.

L’intérêt est concret, mais la méthode compte davantage que l’outil. Il faut choisir un processus récurrent et borné, cartographier ses états et ses effets externes, construire un petit harness, puis tester en bac à sable. Les actions sensibles gardent une approbation humaine. Chaque exécution est journalisée. Des critères d’arrêt empêchent l’agent d’insister lorsqu’il ne comprend plus la situation.

L’objectif n’est donc pas l’autonomie totale. C’est une autonomie délimitée, observable et révocable là où elle peut réellement l’être.

Le problème que ça résout

Les interfaces graphiques ont été conçues pour nos yeux et nos mains. Un bouton change de place. Une fenêtre modale apparaît. Un menu dépend de l’élément sélectionné. Une animation retarde le chargement. Pour un humain, ces détails sont parfois agaçants. Pour un agent, ils peuvent modifier toute la trajectoire d’exécution.

La solution la plus visible consiste à donner à l’agent une capture d’écran, un curseur et la permission de cliquer. Cela produit des démonstrations impressionnantes. En production, le décor devient moins flatteur.

L’agent doit interpréter des pixels, retrouver la bonne zone, comprendre l’état courant et vérifier que son action a eu l’effet prévu. Si le logiciel répond lentement, si un dialogue inattendu s’ouvre ou si la résolution change, la séquence peut dérailler. Et lorsque l’action échoue, il reste souvent une question embarrassante : que s’est-il réellement passé ?

Une PME n’a pas besoin d’un agent qui ressemble à un collègue très rapide devant un écran. Elle a besoin d’un opérateur logiciel dont les actions peuvent être comprises, limitées et contrôlées.

Prenons un processus banal : préparer chaque semaine une série de documents à partir d’un modèle, les convertir dans un format défini, appliquer une convention de nommage et les ranger dans un dossier. Un agent pilotant l’interface à vue doit reconnaître chaque bouton. Une interface de commande peut exposer des opérations plus nettes : ouvrir le modèle, remplacer certains champs, exporter le document, vérifier le fichier produit.

Cette différence change la nature du contrôle. Une commande possède des paramètres. Elle renvoie un statut. Elle peut produire une sortie structurée. Elle peut être testée séparément avant d’être confiée à un agent.

Le problème ne disparaît pas pour autant. Il se déplace vers un endroit plus sain : la conception du contrat entre l’agent et le logiciel. Quels verbes sont autorisés ? Quels objets peuvent être modifiés ? Quels états sont valides ? Quelle preuve confirme la réussite ? Voilà des questions qu’une équipe peut examiner avant le premier lancement.

Dans une PME belge de 10 à 50 personnes, cette explicitation a une valeur particulière. Les responsabilités sont souvent concentrées. La même personne peut connaître le processus métier, administrer un outil et valider le résultat. Un automatisme opaque crée vite une dépendance. Une surface d’action documentée transforme au contraire une partie du savoir tacite en règles inspectables.

Ce que c'est concrètement

CLI-Anything est un projet public écrit en Python et distribué sous licence Apache-2.0. Créé le 8 mars 2026, il avait reçu sa dernière poussée de code le 22 septembre 2026 lors de la vérification des métadonnées. Son ambition est de générer des interfaces en ligne de commande adaptées au pilotage de logiciels par des agents.

Le projet annonce un pipeline en sept phases : analyse du logiciel, conception de l’interface, implémentation, préparation du plan de tests, écriture des tests, documentation et publication. Cette séquence mérite l’attention. Elle place les tests et la documentation dans le processus de génération, au lieu de traiter la commande comme un simple raccourci ajouté après coup.

Le README indique aussi que les interfaces produites peuvent fournir des sorties lisibles par un humain ou structurées en JSON. Le premier format aide l’opérateur à comprendre ce qui vient de se passer. Le second permet à l’agent ou à un système tiers de traiter le résultat sans devoir interpréter une phrase ambiguë.

Autre élément intéressant : le maintien d’un état persistant avec des fonctions d’annulation et de rétablissement. C’est utile pour les modifications internes au logiciel. Il faut toutefois résister à une confusion fréquente. Annuler un changement dans un document n’annule pas nécessairement ses effets externes. Un fichier déjà envoyé, une facture transmise ou une publication rendue visible ne rentrent pas dans le logiciel lorsque l’on exécute une commande d’annulation.

Le projet affirme s’intégrer aux vrais moteurs des applications, plutôt que de construire une imitation isolée. Les exemples cités comprennent GIMP, Blender, LibreOffice, Audacity et QGIS. Le README annonce la prise en charge de 18 applications.

Cette largeur ne prouve pas que chaque intégration convient à un usage métier précis. Elle montre surtout que le principe peut s’appliquer à plusieurs familles de logiciels : création graphique, bureautique, audio, modélisation et cartographie.

Le nombre de tests affiché par le projet a déjà évolué entre différentes communications. Le README consulté en annonce 2 461, alors qu’une publication antérieure en mentionnait 2 280. Ce sont des chiffres déclarés par le projet, pas le résultat d’un audit indépendant. Leur évolution est normale dans un dépôt actif, mais elle ne mesure ni la couverture de votre scénario, ni la sécurité de vos données, ni la qualité d’une intégration particulière.

Une longue suite de tests peut rassurer. Elle ne remplace pas votre propre preuve sur votre propre processus.

Comment s'en servir

Pour une PME, le bon point de départ n’est pas « quel logiciel pouvons-nous automatiser ? ». La question utile est plus étroite : quelle opération récurrente pouvons-nous borner assez clairement pour savoir si elle a réussi ou échoué ?

Étape 1 : choisir un processus récurrent et borné

Commencez par une tâche répétée, stable et peu ambiguë. Elle doit avoir un début identifiable, une fin vérifiable et un volume raisonnable d’exceptions.

La génération périodique de documents depuis un modèle peut convenir. Le classement de fichiers selon des règles simples aussi. En revanche, « gérer toute l’administration » n’est pas un processus. C’est un territoire rempli de décisions, de permissions et d’exceptions.

Décrivez l’entrée attendue, le résultat produit et les cas qui imposent un arrêt. Si l’équipe ne peut pas expliquer le processus sur une page, l’agent ne le rendra pas soudainement limpide.

Étape 2 : cartographier les droits, les états et les effets externes

Listez les objets que l’agent peut lire, créer, modifier et supprimer. Distinguez ensuite trois catégories : l’état interne du logiciel, les fichiers ou données partagés avec d’autres systèmes, et les effets externes sur des personnes ou des organisations.

Cette distinction évite de présenter un undo comme une garantie universelle. Revenir à la version précédente d’un fichier est une opération interne. Remplacer un fichier synchronisé peut déjà toucher d’autres utilisateurs. Envoyer un document à un client produit un effet externe qui ne s’efface pas avec une commande de retour arrière.

Appliquez le minimum de droits nécessaires. Un agent chargé de convertir des documents n’a pas besoin d’accéder à toute l’arborescence de l’entreprise.

Étape 3 : construire un petit harness

Le harness est la couche qui encadre l’outil. Il prépare les entrées, appelle les commandes autorisées, valide les sorties et refuse les comportements hors périmètre.

Gardez-le petit. Quelques commandes bien comprises valent mieux qu’un catalogue entier exposé dès le premier jour. Définissez des paramètres obligatoires, des formats acceptés, des limites de taille et des dossiers précis. Le harness doit aussi vérifier les préconditions. Un fichier existe-t-il ? Le format est-il permis ? Le dossier de sortie est-il accessible ? L’opération demandée appartient-elle au scénario autorisé ?

L’agent choisit parmi des actions prévues. Il ne reçoit pas les clés de tout le logiciel.

Étape 4 : tester en bac à sable

Utilisez des copies de fichiers et des données fictives ou correctement anonymisées. Isolez le bac à sable des dossiers de production et désactivez les canaux externes inutiles.

Testez le chemin normal, puis les situations qui font trébucher les automatismes : fichier manquant, format incorrect, doublon, nom invalide, espace insuffisant, application indisponible, état incomplet. Vérifiez aussi le comportement après une interruption.

Le test ne doit pas seulement confirmer que la commande fonctionne. Il doit montrer qu’elle échoue proprement, sans modifier autre chose et sans masquer l’erreur.

Étape 5 : journaliser chaque exécution

Conservez l’identité de l’appelant, la commande demandée, les paramètres utiles, l’heure, le statut et la preuve du résultat. Évitez toutefois de recopier des secrets ou des données personnelles dans les journaux.

Une sortie JSON facilite cette discipline, car elle peut contenir un statut, les objets modifiés, les avertissements et les erreurs dans un format stable. L’équipe doit pouvoir reconstruire la séquence sans relire une conversation entière avec l’agent.

Un journal n’empêche pas l’incident. Il rend l’incident explicable.

Étape 6 : imposer une approbation humaine aux actions sensibles

Toute action ayant un impact financier, juridique, commercial ou externe mérite un point de contrôle proportionné. L’agent peut préparer le document, mais une personne approuve son envoi. Il peut proposer une modification importante, mais il ne la rend pas visible sans validation.

L’approbation doit montrer ce qui va changer. Un bouton « confirmer » posé devant une opération opaque ne protège presque rien. Présentez les fichiers concernés, les destinataires, le résumé des modifications et les avertissements éventuels.

La meilleure validation intervient juste avant l’effet sensible, pas au début d’une longue chaîne dont personne ne connaît encore le résultat.

Étape 7 : définir des critères d'arrêt

Un agent doit savoir quand ne plus agir. Fixez un nombre maximal de tentatives, un délai, des états interdits et des erreurs qui imposent une remontée humaine.

Arrêtez l’exécution si le résultat ne peut pas être vérifié, si l’état observé diffère de l’état attendu, si une permission manque ou si l’agent propose une commande hors liste. Arrêtez-la aussi lorsque le coût de vérification dépasse le bénéfice de l’automatisation.

Ces critères ne sont pas un aveu d’échec. Ils constituent la frontière opérationnelle du système.

Ce que ça coûte vraiment

Le logiciel peut être open source. L’intégration, elle, ne devient pas gratuite.

Le premier coût est celui de la compréhension. Quelqu’un doit décrire le processus, identifier ses exceptions et décider ce que l’agent peut faire. Cette personne n’est pas forcément développeuse. Elle doit cependant connaître le travail réel, y compris les petits détours que la procédure officielle oublie.

Vient ensuite le coût technique : installation, adaptation des commandes, construction du harness, gestion des permissions, tests et journalisation. CLI-Anything indique lui-même plusieurs limites. La génération demande des modèles solides. Elle dépend de la disponibilité du code source du logiciel visé. Plusieurs raffinements peuvent être nécessaires. Enfin, la couverture et la sécurité dépendent des tests et du harness mis autour de l’intégration.

Autrement dit, l’interface générée n’est pas une délégation de responsabilité. C’est du code à examiner.

Le coût d’exploitation reste lui aussi présent. Une nouvelle version du logiciel peut modifier une fonction ou un format. Un processus métier peut évoluer. Une personne doit suivre les erreurs, examiner les journaux et décider quand relancer les tests. Il faut également maintenir le bac à sable et les jeux de données de contrôle.

Pour juger l’investissement, comparez le temps réellement économisé au temps de conception, de vérification et de maintenance. Ajoutez le coût d’une erreur plausible. Une tâche courte, rare et sensible se prête mal à cette approche. Une opération fréquente, stable et facile à vérifier offre un terrain plus raisonnable.

La bonne unité de mesure n’est pas le nombre de clics supprimés. C’est le nombre d’exécutions utiles que l’équipe peut vérifier sans augmenter un risque qu’elle ne maîtrise pas.

Pour qui ce n'est pas

Cette approche convient mal aux équipes qui cherchent une autonomie immédiate sans consacrer de temps aux tests. Générer une interface de commande ne transforme pas un processus flou en système fiable.

Elle n’est pas adaptée non plus à un logiciel fermé dont les fonctions nécessaires ne sont pas accessibles, surtout si l’intégration dépend de son code source. Dans ce cas, une API officielle, un export contrôlé ou une automatisation plus classique peut offrir une surface mieux supportée.

Évitez aussi d’en faire le premier choix pour un processus dominé par des exceptions humaines : négociation commerciale, décision RH délicate, arbitrage juridique ou communication de crise. Un agent peut préparer des éléments. La décision reste liée au contexte, à la responsabilité et parfois à des informations absentes du logiciel.

Enfin, renoncez lorsque le résultat ne peut pas être vérifié à un coût raisonnable. Automatiser une action dont personne ne sait définir la réussite revient à accélérer une zone grise.

Pour une PME de 10 à 50 personnes, le meilleur projet pilote est presque modeste : périmètre court, données maîtrisées, effet réversible ou soumis à approbation, preuve de sortie évidente. C’est moins spectaculaire qu’un agent libre de cliquer partout. C’est aussi beaucoup plus utile pour apprendre où l’autonomie apporte réellement quelque chose.

Source : https://github.com/HKUDS/CLI-Anything

FAQ

Qu'est-ce qu'un logiciel pilotable par un agent IA ?

C’est un logiciel dont les fonctions utiles sont exposées sous forme d’actions explicites et documentées. L’agent peut appeler une commande avec des paramètres définis, puis lire un résultat vérifiable. Il dépend moins de l’interprétation visuelle d’une interface et davantage d’un contrat d’action contrôlé.

Une interface en ligne de commande suffit-elle à sécuriser un agent ?

Non. Elle rend les actions plus explicites, mais la sécurité dépend encore des permissions, du harness, des tests, de l’isolation et des validations humaines. Une commande parfaitement structurée peut rester dangereuse si elle autorise une suppression trop large ou un envoi sans contrôle.

L'undo permet-il d'annuler toutes les erreurs ?

Non. L’annulation peut restaurer un état interne lorsque le logiciel la prend en charge. Elle ne récupère pas automatiquement un fichier déjà envoyé, une information publiée ou une décision transmise à un système externe. Ces effets demandent une compensation, lorsqu’elle est encore possible.

Quel premier cas d'usage choisir dans une PME belge ?

Choisissez une tâche récurrente, stable, limitée à quelques actions et dotée d’un résultat facile à vérifier. La préparation ou la conversion de documents dans un environnement isolé est souvent plus appropriée qu’un processus impliquant immédiatement des paiements, des clients ou des décisions sensibles.

Faut-il remplacer les logiciels existants ?

Pas nécessairement. L’idée est précisément de construire une surface d’action au-dessus des vrais moteurs des logiciels lorsque cela est possible. La décision dépend toutefois de l’accès technique disponible, de la qualité de l’intégration et du coût de maintenance face aux API ou automatisations déjà supportées.

Comment savoir quand arrêter le projet pilote ?

Arrêtez ou réduisez le périmètre si les erreurs ne sont pas détectables, si les exceptions deviennent la norme, si l’intégration demande des raffinements constants ou si le contrôle humain coûte autant que l’exécution manuelle. Un pilote utile doit clarifier la décision, y compris lorsque la bonne décision est de ne pas automatiser.

---

Publié le 12 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.