Le parcours vers un venture builder assistant

Qu’est-ce que le parcours vers un Venture Builder Assistant ?

Le parcours vers un Venture Builder Assistant, c’est le chemin qui mène d’un lourd plan sur mesure à un petit assistant agentique, construit en blocs remplaçables sur l’écosystème que l’organisation utilise déjà. Le résultat aujourd’hui : un assistant où des agents orchestrés se partagent le travail. À La Plage Factory, il a fallu changer deux fois de plateforme, et les questions, le contenu du programme et la relecture humaine sont restés en place tout au long.

Vous croyez peut-être qu’un assistant agentique nécessite une équipe tech complète. Quand j’ai commencé, c’était vrai. Les outils ont évolué depuis, et la décision qui compte a évolué avec eux. En neuf mois, cette évolution a libéré un énorme potentiel et accéléré l’intégration d’un assistant avec les outils qu’une équipe utilise déjà. Beaucoup de choses restent inconnues. Le coût de construction a baissé. Le coût d’un mauvais choix de fondation, lui, n’a pas baissé.

Cet article passe en revue les décisions dans l’ordre, avec les plateformes, le calendrier et les frictions rencontrées en chemin. Si vous dirigez une PME ou une business unit et qu’un projet d’assistant dort sur votre liste, vous y trouverez une séquence réutilisable.

Chaque section traite d’une décision. Chaque section contient une courte explication des termes et un court récit de ce que j’ai fait. Utilisez l’explication pour comprendre le terme. Utilisez le récit pour voir le choix et son coût.

Pourquoi un assistant agentique ne démarre plus avec une équipe tech

Un assistant agentique reçoit une question, va chercher la bonne matière et propose une réponse. Dans sa forme la plus avancée, il s’appuie sur des agents orchestrés. Plusieurs agents spécialisés accomplissent chacun une tâche précise, et une couche d’orchestration les coordonne. C’est la forme que j’utilise aujourd’hui. L’assistant propose. Une personne décide quoi faire de la proposition.

L’assistant se compose de trois parties. La première est la question de l’utilisateur. La deuxième est la matière que l’assistant trouve. La troisième est la réponse proposée. Une personne lit la réponse et décide de la suite.

Quand j’ai commencé, livrer tout cela supposait du code sur mesure, un ensemble d’agents, des connecteurs pour chaque source de données et une architecture RAG complète. RAG signifie retrieval-augmented generation (génération augmentée par la recherche) : l’assistant récupère des passages de votre propre contenu avant de rédiger une réponse. Ce type de recherche augmentée demandait des ingénieurs pour la construire et la maintenir en fonctionnement.

Un connecteur est un lien entre l’assistant et une source de données. Chaque source de données a besoin de son propre connecteur. Un connecteur cesse de fonctionner quand la source de données change. Un ingénieur doit alors le réparer.

Les grands éditeurs ont depuis ajouté des connecteurs en natif, renforcé MCP (le Model Context Protocol, un standard pour connecter les assistants aux outils et aux données) et lancé des fonctionnalités agentiques comme Claude Cowork. Ce qui relevait du travail de projet relève désormais de paramètres et de licences. Un petit groupe peut atteindre une première version fonctionnelle : une personne qui connaît le contenu, une personne capable de configurer la plateforme et une poignée d’utilisateurs pilotes.

Cela ne supprime pas le besoin de compétences. Quelqu’un doit toujours définir les questions, organiser le contenu et tester avec de vrais utilisateurs. Ce qui disparaît, c’est l’idée que tout cela attend dans la file d’attente de l’ingénierie.

Le vrai risque : un développement enfermé dans une stack qui bouge chaque semaine

Quand vous construisez sur mesure, vous possédez les connecteurs, la couche de recherche et la logique des agents. Chacun est un travail que vous devez maintenir. Quand les éditeurs livrent la même capacité en natif, vous avez deux options. Refaire votre travail sur la version native, ou jeter le vôtre. Dans les deux cas, le temps déjà investi n’a aucune valeur de revente.

C’est pourquoi je me suis retenu de lancer un développement sur mesure lourd sur ce projet. Les grands éditeurs ajoutaient des connecteurs, un MCP plus solide et des fonctionnalités agentiques, et la direction était visible. Décider quoi laisser de côté a gardé le projet facile à déplacer. Un composant que vous n’avez pas construit ne peut pas devenir une migration.

Une migration, c’est le travail nécessaire pour passer d’un composant à un autre. Elle exige une nouvelle configuration. Elle exige une nouvelle série de tests. Elle bloque les autres chantiers pendant sa durée. Un petit projet ressent davantage ce coût qu’un grand, car les mêmes personnes font les deux métiers.

Voici le test que j’applique désormais avant toute construction. Pour chaque composant, demandez-vous si un grand éditeur est susceptible de le livrer dans les deux prochains trimestres. Si la réponse est oui, louez-le ou attendez. Ne construisez que ce qui est propre à votre organisation. Dans ce cas, c’étaient les questions, le contenu du programme et la boucle de relecture avec des personnes.

Ce que La Plage Factory attendait de l’assistant

La Plage Factory gère un programme d’incubation pour startups. Les fondateurs et les mentors avaient besoin de réponses ancrées dans ce programme et reliées au contexte de chaque startup et à sa progression dans Vianeo Business Design, la méthode de business design que parcourent les startups.

Une même question peut appeler une réponse différente selon l’avancement de la startup dans ce travail. Un fondateur qui demande comment tester un segment de clientèle a besoin d’une réponse au début, et d’une autre une fois que des preuves sont arrivées. Un chatbot générique ne peut pas faire la différence. L’assistant avait besoin du contenu du programme, du contexte de la startup et de l’étape de travail, tous en même temps.

L’assistant utilise trois entrées. La première est le contenu du programme. La deuxième est le contexte de la startup. La troisième est l’étape de travail. Si une entrée manque, la réponse est moins utile pour le fondateur.

C’est de cette exigence que naît l’autorité sémantique. Une réponse a du poids quand elle s’ancre dans ce que le programme a distillé et qu’elle est façonnée par la position propre de la startup. J’ai aussi fixé un standard pour la lecture des réponses. Elles devaient aller droit au but et être écrites dans une voix de CEO : courtes, précises, quelque chose qu’un fondateur peut appliquer le jour même.

Avant de choisir le moindre outil, j’ai noté les questions que posent réellement les fondateurs et les mentors. Cette liste est devenue le jeu de tests de chaque version suivante. Chaque nouvelle version devait répondre à la même liste. Cela m’a donné une manière fixe de comparer les versions.

Ce qu’il faut laisser de côté dans une première version

Le plan initial prévoyait du code sur mesure, un ensemble d’agents et une architecture RAG complète. Avec le recul, quatre éléments sont restés hors du développement parce qu’un éditeur était susceptible de les couvrir :

• Des connecteurs sur mesure vers les documents et les outils de l’organisation.
• Une couche de recherche développée en interne.
• Un framework d’agents développé en interne.
• Tout ce qui dépendait d’un modèle spécifique.

Chaque élément de cette liste présente le même risque. Un éditeur peut le livrer. Votre propre version devient alors un doublon que vous devez maintenir.

Laisser tout cela de côté a rendu la première version plus petite et chaque changement ultérieur moins coûteux. L’effort s’est concentré sur les questions et le contenu, que nul éditeur ne peut fournir.

Choisir Microsoft Copilot pour un assistant agentique

Il y a quatre mois, j’ai choisi Microsoft Copilot, puisque La Plage fonctionne déjà sur Microsoft. Les comptes, l’identité, les documents et les permissions y vivent déjà. Le modèle n’est qu’une partie du système. L’écosystème autour du modèle pèse davantage : ce à quoi il se connecte, qui est déjà connecté et ce que l’organisation a déjà approuvé. L’intégration avec ce que l’organisation utilise déjà compte plus que le modèle seul.

L’identité signifie que le système sait qui est l’utilisateur. Les permissions signifient que le système sait ce que l’utilisateur peut lire. L’assistant doit respecter les deux. Quand l’assistant s’appuie sur la configuration Microsoft existante, l’organisation n’a pas besoin de reconstruire ces contrôles.

Pour la plupart des dirigeants de PME et de business units, la même logique s’applique. Choisissez la plateforme que vos équipes ouvrent déjà chaque matin. La friction d’adoption est plus faible, et les questions de sécurité ont des réponses plus courtes. Une option techniquement plus puissante hors de votre écosystème coûte généralement plus en conduite du changement qu’elle ne rapporte en qualité.

Construire un assistant agentique en blocs

J’ai construit en blocs, et chaque bloc a été testé avec de vrais utilisateurs avant l’ajout du suivant. L’ordre était le suivant :

1. Un agent, qui répond à la vraie liste de questions à partir du contenu du programme.
2. Azure, pour gérer le paiement des tokens à l’usage.
3. Power Automate, pour connecter l’assistant aux workflows qui l’entourent.

Un token est une petite unité de texte. Le modèle lit des tokens et écrit des tokens. L’éditeur facture chaque token utilisé par le modèle. Azure gère ce paiement, de sorte que le coût d’usage est visible et maîtrisé.

Un workflow est une série d’étapes qu’un outil exécute dans un ordre fixe. Power Automate relie l’assistant aux workflows qui existent déjà autour de lui. L’assistant s’intègre alors au travail quotidien de l’équipe.

Tester entre chaque bloc donne un signal net. Si quelque chose casse ou déroute les utilisateurs, vous savez quel bloc en est la cause. Je surveille aussi l’engagement pondéré. Une poignée de fondateurs et de mentors qui reviennent chaque semaine m’en apprennent plus qu’un jour de lancement rempli de premiers clics par curiosité. Ceux qui reviennent sont ceux dont les questions améliorent l’itération suivante.

Le passage au harness GitHub Copilot et aux agents orchestrés

Il y a trois mois, je suis passé au harness GitHub Copilot, toujours en bêta. Ce changement a apporté les agents orchestrés dans l’assistant. C’est la partie la plus importante du résultat que j’ai mis en place. Azure et Power Automate n’ont cessé d’évoluer. Il a fallu environ six appels au support Microsoft, car la documentation était absente ou en retard. C’est le prix à payer pour construire sur une plateforme qui bouge.

Agents orchestrés signifie que plusieurs agents travaillent sur une même demande. Chaque agent a une tâche précise. Une couche d’orchestration fixe l’ordre, transmet la sortie d’un agent au suivant et renvoie une seule réponse proposée. Une personne décide toujours quoi faire de cette réponse.

Un agent unique doit porter tout le travail. Avec des agents orchestrés, chaque agent peut être testé, modifié ou remplacé séparément. Cela s’accorde avec l’approche par blocs. Chaque agent est un bloc. L’assistant peut grandir un agent à la fois, et les réponses parviennent au fondateur avec un travail réparti entre les agents.

Un harness est la couche qui exécute les agents. Il leur donne leurs outils et leurs règles. Bêta signifie que l’éditeur peut encore modifier le produit. Anticipez ces changements avant de commencer.

Aujourd’hui, vous pouvez même choisir le modèle de votre goût dans les agents Copilot. Cette option n’existait pas quand j’ai commencé, et elle montre pourquoi une décision centrée sur le modèle aurait vieilli très vite.

Le coût est resté gérable parce que chaque bloc était petit. Le changement a signifié la reconstruction d’une seule couche, la plus proche de la plateforme. Les questions, le contenu du programme et la relecture humaine sont restés en place. Les actifs qui portent la valeur se trouvaient en dehors de la couche qui a changé.

Garder les humains aux commandes de chaque réponse

L’assistant propose des réponses. Les fondateurs et les mentors choisissent. Un mentor lit une réponse proposée, l’ajuste en fonction de ce qu’il sait du fondateur et la transmet. Ce que le programme distille de ces échanges alimente la prochaine itération du contenu. Cette boucle améliore l’assistant sans lui confier la décision.

La boucle comporte cinq étapes :

1. Le fondateur pose une question.
2. L’assistant propose une réponse.
3. Le mentor lit la réponse et la modifie si nécessaire.
4. Le mentor envoie la réponse au fondateur.
5. Le programme distille l’échange et met à jour le contenu.

C’est aussi une garantie pratique. Une réponse sur la stratégie d’une startup a des conséquences. La personne qui connaît le contexte doit en être responsable. L’assistant change la manière de faire le travail. Le rôle du mentor reste ce qu’il était.

Trois règles qui tiennent aujourd’hui

1. Commencez par les questions que les gens posent. Les questions d’abord, l’outillage ensuite.
2. Choisissez un écosystème et construisez en blocs. D’abord un agent, puis les couches autour, jusqu’à ce que des agents orchestrés se partagent le travail.
3. Gardez les humains décisionnaires. L’assistant propose, les personnes choisissent, et ce que le programme distille alimente le tour suivant.

En neuf mois, les outils ont libéré un énorme potentiel et rendu l’intégration beaucoup plus rapide. Les agents orchestrés sont la partie du résultat que je citerais en premier. Beaucoup de choses restent inconnues, y compris la prochaine couche qui bougera. Démarrez sur les outils les plus récents et attendez-vous à itérer. Choisissez l’option qui correspond à votre écosystème aujourd’hui, et gardez chaque bloc assez petit pour pouvoir le remplacer quand la plateforme bougera de nouveau.

Par où commencer sur votre propre liste

Regardez votre liste de projets et repérez celui qui attend de la capacité d’ingénierie. Ce pourrait être un assistant pour les playbooks commerciaux, l’onboarding ou les questions de politique interne. Notez les vingt questions les plus fréquentes. Vérifiez quel écosystème vos équipes utilisent déjà. Construisez un agent dessus, testez-le avec cinq vrais utilisateurs et décidez après deux semaines s’il faut ajouter le bloc suivant.

À la fin des deux semaines, répondez à ces questions :

1. Les cinq utilisateurs reviennent-ils sans relance ?
2. Les relecteurs modifient-ils beaucoup de réponses proposées ?
3. De quel bloc l’équipe a-t-elle besoin ensuite ?

Si les réponses sont claires, ajoutez le bloc suivant. Si elles ne le sont pas, corrigez d’abord le contenu ou les questions.

Une mise en garde tirée de l’expérience. Un assistant amplifie le processus qui le sous-tend. Si le processus est défaillant, l’assistant accélère la défaillance. Partez de la douleur, corrigez le processus, puis ajoutez l’outil.

Quel projet de votre liste attend une équipe tech dont il n’a peut-être plus besoin ?

FAQ

Qu'est-ce qu'un assistant agentique ?

Un assistant agentique est un logiciel qui reçoit une question, récupère la matière pertinente et propose une réponse. Dans sa forme avancée, il s’appuie sur des agents orchestrés : plusieurs agents spécialisés, coordonnés pour travailler sur une même demande. Il recommande et une personne décide. À La Plage Factory, il répond aux fondateurs et aux mentors à partir du programme d’incubation et de la progression de chaque startup dans Vianeo Business Design.

Que sont les agents orchestrés ?

Les agents orchestrés sont plusieurs agents qui travaillent sur une même demande. Chaque agent a une tâche précise. Une couche d’orchestration fixe l’ordre et renvoie une seule réponse proposée. Dans l’assistant de La Plage Factory, ils sont arrivés avec le passage au harness GitHub Copilot, et chaque agent peut être testé ou remplacé séparément.

Ai-je besoin d'une équipe tech pour construire un assistant agentique ?

Pas pour une première version. Les éditeurs livrent désormais en natif des connecteurs, la prise en charge de MCP et des fonctionnalités agentiques, de sorte qu’une personne disposant des bons accès peut configurer un agent fonctionnel. Il vous faut toujours quelqu’un qui définit les questions, organise le contenu et teste avec de vrais utilisateurs.

Pourquoi choisir Microsoft Copilot pour un assistant agentique ?

Dans ce projet, la raison tenait à l’écosystème. La Plage fonctionne déjà sur Microsoft, donc l’identité, les documents et les permissions étaient en place. L’intégration avec ce que l’organisation utilise déjà pèse plus que le modèle seul.

Comment éviter l'enfermement technologique en construisant un assistant agentique ?

Construisez en petits blocs et laissez de côté tout ce qu’un éditeur est susceptible de livrer bientôt. Gardez les questions, le contenu et la relecture humaine en dehors de la couche plateforme. Quand La Plage est passée au harness GitHub Copilot, une seule couche a dû être reconstruite.

Qui prend la décision finale, l'assistant ou les personnes ?

Les personnes. L’assistant propose des réponses, et les fondateurs et les mentors choisissent ce qu’ils en font. Ce que le programme distille de ces choix alimente l’itération suivante.