Construire des plateformes agentiques d’entreprise : les leçons de NOVA

Qu’est-ce qu’une plateforme agentique d’entreprise ?

Ce n’est pas un chatbot avec des plug-ins. C’est un système en couches qui transforme une intention en plan, exécute des compétences versionnées par des agents spécialisés et livre un résultat relisable. NOVA est ma tentative, déployée auprès de 800 collaborateurs chez Devoteam.

J’utilise trois questions pour tester toute plateforme qui se dit agentique. Qui est responsable du contexte ? Qui décide de ce qu’un agent peut faire seul ? Qui prouve qu’une nouvelle version est meilleure que la précédente ? Si les réponses sont le prompt, le modèle et la démo, c’est un assistant avec de l’ambition, pas une plateforme. La suite de l’article suit ces trois questions, qui correspondent aux briques agir, savoir et apprendre.

Pourquoi un orchestrateur unique plutôt qu’un menu d’agents ?

NOVA est organisé en couches. Un orchestrateur unique cadre la demande, planifie, délègue aux spécialistes, supervise le travail et assemble le résultat. Derrière lui, des agents spécialisés en produit, projet, design et ingénierie maîtrisent chacun un domaine avec leurs compétences versionnées. Un agent de recherche apporte le contexte, et un agent de validation contrôle chaque livrable avant qu’il n’atteigne l’utilisateur.

L’utilisateur ne choisit jamais un agent. Cela ressemble à un détail d’ergonomie, mais c’est la principale décision d’adoption : personne ne veut apprendre l’organigramme d’une équipe de robots. Les gens veulent dire ce qu’ils cherchent à accomplir et recevoir un travail qu’ils peuvent modifier.

Le résultat compte autant que le routage. Le dépôt public de NOVA décrit des livrables sous forme d’artefacts structurés, versionnés et modifiables, avec citations, et non de messages de chat à recopier ailleurs. C’est ce qui rend le résultat relisable par un humain, et la relecture est le moment où la confiance se construit.

Pourquoi le contexte est-il un produit et non un prompt ?

La plupart des échecs que j’ai vus n’étaient pas des échecs du modèle. Des agents citaient une décision remplacée, mélangeaient deux versions d’une spécification, ignoraient une contrainte ou, pire, exposaient un document à quelqu’un qui n’aurait jamais dû le voir. Un meilleur modèle ne corrige rien de tout cela.

NOVA récupère donc son contexte via ORBIT, au nom de l’utilisateur et avec ses droits, et une réponse peut dire pourquoi une source a été retenue ou écartée. Traiter le contexte comme une couche gouvernée rend la plateforme plus fiable et plus facile à auditer. D’après le README public, ORBIT travaille sur ces points :

La conséquence pratique, c’est une autre façon de déboguer. Quand une réponse est fausse, je ne commence plus par réécrire le prompt. Je regarde quelles sources ont été récupérées, lesquelles ont été écartées et pourquoi. Le plus souvent, la correction est un document périmé, une habilitation manquante ou une contradiction non résolue entre deux sources, et rien de tout cela n’est visible depuis le prompt.

• Ingestion des sources de l’équipe avec détection et caviardage des données personnelles.
• Une mémoire vivante des décisions, contraintes et risques, avec un cycle de vie (proposé, validé, remplacé, obsolète, oublié) et une provenance.
• Habilitations et classification des données appliquées avant que quoi que ce soit n’atteigne un agent.
• Un code de raison explicable pour chaque élément retenu ou écarté d’un contexte.
• Des connecteurs vers les outils que les équipes utilisent déjà, dont des connecteurs MCP.

Comment NOVA, ORBIT et FORGE se répartissent-ils le travail ?

J’ai séparé volontairement les trois responsabilités, car les mélanger est ce qui rend une plateforme impossible à raisonner. NOVA ne duplique jamais ORBIT ni FORGE : il demande son contexte à ORBIT et il est évalué par FORGE via un adaptateur.

Pourquoi évaluer avant de passer à l’échelle ?

Une plateforme utilisée par des centaines de personnes ne peut pas reposer sur l’impression que « ça semble mieux ». Chaque version est évaluée et testée en non-régression avec FORGE avant d’atteindre plus d’utilisateurs. Le README de FORGE décrit des scénarios, des règles déterministes, des juges LLM, une évaluation humaine et des expériences de référence contre candidat, avec des scores qui remontent toujours à un critère et à une étape de l’exécution.

Je préfère le dire clairement : un score sans explication est une rumeur. Si une évaluation ne peut pas montrer quel critère et quelle étape ont produit un chiffre, personne ne peut agir dessus.

J’ai aussi appris à garder le jeu d’évaluation honnête. Le README de FORGE décrit des scénarios publics, privés et frais, pour qu’une équipe ne puisse pas optimiser discrètement les tests qu’elle voit. C’est la partie de l’évaluation que la plupart des équipes sautent, et c’est celle qui protège d’un benchmark flatteur.

Qui apprend vraiment dans une plateforme qui apprend ?

« FORGE apprend » est un raccourci, et il peut induire en erreur. Personne n’entraîne les poids d’un modèle dans ce dispositif. FORGE produit des preuves. NOVA les distille en courtes leçons, c’est-à-dire des instructions versionnées, et les déploie via une porte de preuve, un canari et une approbation, avec possibilité de retour arrière. ORBIT conserve les apprentissages gouvernés que NOVA récupère ensuite comme contexte.

Cette séparation compte dans une grande entreprise. Des instructions peuvent être relues, comparées et annulées. Des poids ne le peuvent pas, du moins pas par ceux qui portent le processus métier.

Comment garder l’autonomie sous contrôle ?

L’autonomie est un curseur, pas un interrupteur. La capacité d’ingénierie de NOVA, qui spécifie, code, teste et ouvre des pull requests, propose un mode guidé où un humain valide le plan et la fusion, et un mode autopilote qui va plus loin seul. Voici les contrôles que je considère non négociables :

• Des validations humaines aux étapes qui touchent des systèmes externes.
• Une provenance enregistrée, pour qu’un utilisateur puisse demander pourquoi un élément a été retenu.
• Une politique d’autonomie et un registre d’outils, pour que les agents n’utilisent que ce qui leur est permis.
• Des versions proposées plutôt que des mises à jour silencieuses quand une source citée change.
• Le rejeu d’une exécution terminée sans écriture vers des systèmes externes, pour comparer coût, durée et contexte.

Qu’ai-je mesuré et observé ?

Je dois être prudent ici. NOVA, ORBIT et FORGE sont des bêtas publiques, et je décris leur conception, pas une garantie de production. Les chiffres que je peux assumer viennent du travail de plateforme qui les entoure.

Chez Devoteam, NOVA a atteint 800 collaborateurs grâce à une équipe pluridisciplinaire de 15 personnes, au sein d’un groupe de plus de 10 000 consultants dans 25 pays. Sur la plateforme DILA du secteur public, la même discipline de composants partagés et d’évaluation a produit les résultats ci-dessous.