Article publié à l'origine en anglais.

Quand les machines se sont mises à parler la même langue

Dans les années 1990, un consortium de constructeurs d'équipements et d'organismes d'ingénierie agricole s'est attaqué à un problème qui freinait l'agriculture de précision. Chaque constructeur exploitait son propre protocole de communication pour les échanges de données entre l'outil et le tracteur. Un tracteur John Deere et un pulvérisateur Hardi ne pouvaient pas partager un langage de données sans intégration sur mesure. Faire circuler l'information de manière fiable entre des machines de différents constructeurs était coûteux, fragile et hors de portée de la plupart des exploitations.

La solution a été l'ISO 11783, mieux connue sous le nom d'ISOBUS : une norme de communication partagée à laquelle tout constructeur conforme peut se conformer, quelle que soit la marque. Une fois qu'un outil et un tracteur respectent tous deux la norme, les données circulent entre eux. L'opérateur travaille avec l'ensemble du système plutôt que de gérer la traduction entre les composants.

ISOBUS n'a rendu aucune machine plus intelligente individuellement. Elle a rendu possible la relation entre les machines.

Cette distinction, entre améliorer un composant et permettre une relation, est ce à quoi je réfléchis depuis le 22 avril.

Ce qui s'est passé à Google Cloud Next à Las Vegas

Le 22 avril, Google a publié un protocole appelé A2A (Agent-to-Agent) accompagné d'une implémentation de référence appelée Agent Gateway. Google décrit le Gateway comme le « contrôleur aérien » des opérations multi-agents : une couche qui inspecte, gouverne et achemine les communications entre agents IA, outils tiers et sources de données.

A2A n'est pas un produit. C'est une norme proposée pour la manière dont les agents IA communiquent entre eux.

Le lancement s'est accompagné d'engagements de plus de 50 partenaires technologiques : Atlassian, Salesforce, SAP, ServiceNow, Workday, LinkedIn, PayPal et d'autres. Ce ne sont pas des acteurs marginaux : c'est la pile logicielle d'entreprise qui fait tourner les RH, les achats, la finance et les opérations dans les grandes organisations mondiales. Lorsque ce groupe valide une norme de communication dès le premier jour, l'annonce passe du statut de proposition à celui de décision d'infrastructure.

Reste à voir si A2A deviendra ce point d'inflexion pour les systèmes d'intelligence. Mais les conditions qui ont rendu ISOBUS décisif sont présentes : un problème structurel, une norme proposée, et une part suffisante de l'écosystème engagée à la mettre en œuvre dès le premier jour.

Pour la gestion du gazon et des installations sportives, le parallèle est plus proche que le cadrage « logiciel d'entreprise » ne le laisserait penser, non pas au niveau de l'agent IA, que ce secteur n'a pas encore atteint, mais au niveau de la couche de données, à laquelle il est confronté en ce moment même.

Un parcours de golf ou une installation sportive bien équipés en 2026 font tourner une station météo sur sa propre plateforme, une flotte de tondeuses robotisées sur une deuxième, des capteurs de sol sur une troisième, un contrôleur d'irrigation sur une quatrième. Les registres de pulvérisation vivent ailleurs : dans un tableur, dans une application autonome, ou dans un carnet papier rangé dans l'atelier d'entretien. En principe, certaines de ces données pourraient circuler entre les systèmes. En pratique, les connecter exige des travaux d'intégration sur mesure, une maintenance continue, et dépend de fournisseurs qui ont peu d'intérêt commercial à rendre les données de leurs concurrents plus utiles. Le greenkeeper reste la couche d'intégration, non pas entre agents IA, mais entre plateformes de données.

Ce n'est pas le problème des agents IA. La gestion du gazon n'a pas encore déployé d'agents IA comme l'a fait le logiciel d'entreprise. Le secteur s'attaque à un défi antérieur et plus immédiat : faire en sorte que la couche de données IoT se parle à elle-même. Mais le problème structurel est identique à celui qu'A2A est conçu pour prévenir au niveau des agents. Des silos propriétaires. Des formats de données incompatibles. Aucune norme convenue pour la communication entre les parties. Et la personne qui se tient entre elles pour faire la traduction.

Le problème de la mise en production

Parallèlement à l'annonce d'A2A, Gartner a publié un chiffre qui circule dans l'industrie de l'IA : 86 à 89 % des programmes pilotes d'agents IA n'ont pas atteint la production à grande échelle.

Ce chiffre est souvent lu comme un commentaire sur la maturité de l'IA, comme si la technologie n'était pas encore assez fiable. Je pense qu'il décrit quelque chose de plus structurel : un problème de fragmentation. La plupart des pilotes d'IA en entreprise qui échouent en production n'échouent pas parce que le raisonnement était faux, mais parce que la sortie d'un système ne dispose d'aucun mécanisme standard pour la transmettre au suivant. Pas de protocole partagé. Pas de format convenu. Quelqu'un doit assurer le transfert manuellement, à intervalles réguliers, l'information arrivant trop tard pour être utile.

Les opérations de gazon reconnaîtront la forme de ce problème, même si la couche technologique est différente. Une plateforme météo qui ne peut pas exporter directement vers un outil de planification nutritionnelle. Un tableau de bord de capteurs de sol sans connexion native vers le contrôleur d'irrigation. Un registre de pulvérisation qui vit dans un environnement séparé du modèle de risque de maladie qui devrait le lire. Le problème d'architecture est le même. La couche où il apparaît est différente.

La forme de ce problème est familière à partir de l'expérience même de l'agriculture de précision il y a dix ans. Les capteurs fonctionnaient. Les machines fonctionnaient. Les formats de données étaient incompatibles. L'opérateur était la couche d'intégration.

La transition vers ISOBUS ne s'est pas faite parce que les machines se sont améliorées. Elle s'est faite parce que le secteur s'est mis d'accord sur une grammaire, et une fois cette grammaire en place, chaque nouvel outil pouvait y participer sans nécessiter d'intégration sur mesure.

A2A propose la même grammaire pour les agents IA. Pas un modèle partagé, pas une plateforme partagée, mais un protocole partagé. La distinction compte, car elle signifie que les agents peuvent provenir de différents fournisseurs, fonctionner sur différents modèles sous-jacents, et continuer à communiquer dans une architecture gouvernée.

La question que cela soulève pour les opérations

Pour un directeur d'agronomie ou un responsable d'exploitation qui évalue la technologie, la version pertinente de la question A2A ne porte pas encore sur les agents IA. Elle porte sur les données.

Cette plateforme se connecte-t-elle aux autres plateformes de mon exploitation, ou crée-t-elle un silo supplémentaire ? Exporte-t-elle les données dans des formats ouverts, ou enferme-t-elle mes registres opérationnels (registres de pulvérisation, mesures de sol, données de croissance) à l'intérieur d'un environnement propriétaire ? Puis-je déplacer mes données si je change de fournisseur, ou en ai-je cédé le contrôle en même temps que le contrat ?

Ce sont les questions sur lesquelles le secteur du gazon travaille en ce moment, au niveau des données et des API. A2A est la même question en train d'être tranchée un cran au-dessus, dans le logiciel d'entreprise : lorsque les agents IA deviendront l'interface principale, communiqueront-ils via des normes ouvertes, ou chaque fournisseur dressera-t-il des murs autour de ses agents, comme les constructeurs d'équipements dressaient autrefois des murs autour de leurs protocoles d'outils ?

Les deux questions sont liées. Les décisions architecturales prises aujourd'hui au niveau de la couche de données détermineront avec quelle facilité une couche d'intelligence pourra être construite par-dessus plus tard. Une plateforme qui enferme vos registres opérationnels dans une base de données propriétaire crée, un niveau plus haut, la même contrainte qu'un constructeur d'équipements pré-ISOBUS. Le coût de la mise à niveau arrive plus tard, lorsque changer de fournisseur est devenu cher et que les données sont plus difficiles à déplacer.

Avant ISOBUS, les constructeurs d'équipements avaient des raisons commerciales de garder leurs protocoles propriétaires. Une norme de communication verrouillée signifiait des clients verrouillés. Le passage aux normes ouvertes a été résisté, puis progressivement adopté, puis est devenu la condition préalable à la participation au marché. La même dynamique est à l'œuvre aujourd'hui dans l'infrastructure IA, et dans les plateformes de données agronomiques qui s'installeront en dessous.

Le test pratique s'applique aux deux couches : les plateformes que vous utilisez peuvent-elles partager des données entre elles sans que votre équipe ne médie le transfert ? Si ce n'est pas le cas, si le greenkeeper reste la connexion entre la station météo, le capteur de sol et le registre de pulvérisation, vous avez des composants performants. Vous n'avez pas encore de système. Et vous construisez sur des fondations qui contraindront chaque couche d'intelligence qui suivra.

Pourquoi cela mérite votre attention dès maintenant

Les décisions sur les protocoles font rarement les gros titres. Elles se règlent dans des groupes de travail et des comités techniques, sont annoncées dans des communiqués que la plupart des praticiens ne lisent jamais. Elles sont, invariablement, celles qui déterminent ce que la prochaine décennie d'innovation rendra possible.

Mais la leçon d'ISOBUS, et de chaque moment de normalisation comparable dans l'agriculture de précision, c'est que la décision sur le protocole est celle qui façonne tout ce qui se construit par-dessus. Les outils conçus avant ISOBUS ont exigé des mises à niveau coûteuses ou des remplacements. Les outils conçus après pouvaient participer à un écosystème connecté dès le premier jour.

La couche d'intelligence de votre exploitation : la capacité à relier un relevé météo à une condition de sol, à une décision de pulvérisation, à un résultat observé. Elle sera construite sur des décisions d'infrastructure prises maintenant. Les plateformes auxquelles vous vous engagez. Le fait que vos données opérationnelles vous appartiennent ou soient verrouillées chez un fournisseur. Le fait que l'architecture que vous bâtissez aujourd'hui laisse de la place à une couche d'intelligence connectée, ou la rende impossible.

A2A n'atterrira pas dans la presse spécialisée du gazon. Il ne décrit pas où ce secteur en est actuellement. Mais il décrit, avec précision, le problème d'architecture que chaque couche de technologie opérationnelle finit par devoir résoudre. Il porte la leçon qu'ISOBUS a déjà transmise une fois : choisir le bon protocole avant que l'écosystème ne se verrouille autour du mauvais.

La question à se poser maintenant n'est pas « quel outil donne les meilleures données ? » C'est : quand la couche d'intelligence arrivera, votre exploitation sera-t-elle prête à y participer, ou passerez-vous les trois prochaines années en mises à niveau ?

Référence : le protocole A2A et l'Agent Gateway ont été annoncés à Google Cloud Next '26, Las Vegas, le 22 avril 2026. Sources : Présentation de Google Cloud Next '26 · Kai Waehner, Enterprise Agentic AI Landscape 2026