fr
Chef de projet, Outils
Chef de projet IA : Pourquoi la mise en place d'agents d'IA n'est qu'un projet informatique parmi d'autres
Quelques mois après que l’IA générative soit devenue suffisamment pratique pour construire avec, quelque chose d’intéressant a commencé à se produire de notre côté de FlexiProject – l’équipe commerciale, pas l’équipe d’ingénierie. Sans écrire de code, nous avions soudainement des agents qui exécutaient tranquillement des parties de notre travail quotidien : préparer les offres des clients, remplir les données des contrats, tirer des rapports Search Console, mettre à jour notre backlog de produits après les réunions avec les clients, nous aider à gérer le site Web. Les créer s’est avéré être la partie la plus facile. Ce à quoi nous ne nous attendions pas, c’est que la gestion de projet par l’IA, en traitant chaque agent comme un véritable projet logiciel, avec un plan, une branche partagée, des tests et une étape de livraison, aurait autant d’importance que tout ce que nos ingénieurs avaient jamais expédié. Voici l’histoire de ce que nous avons appris, dans l’ordre où nous l’avons appris.
Dans cet article, vous apprendrez :
|
Comment une équipe commerciale a commencé à créer des agents d'intelligence artificielle
Construire des agents d’IA même si nous ne sommes pas des informaticiens
L’aspect intéressant de ces deux dernières années est que vous n’avez plus besoin d’une équipe de développement pour livrer une IA qui fonctionne. Un professionnel capable de décrire ce qui devrait se passer et de copier quelques exemples d’entrées peut construire un agent qui effectue un véritable travail. Nous n’avions pas prévu de devenir des constructeurs. Nous n’arrêtions pas de nous heurter à des tâches pour lesquelles la réponse était manifestement « cela pourrait être fait par un agent », alors nous avons commencé à construire. La première tâche a pris un après-midi. La deuxième a pris un après-midi. C’est alors que les problèmes ont commencé – non pas avec le bâtiment, mais avec tout ce qui l’entoure.
Les agents que nous avons construits
La liste s’est allongée plus rapidement que prévu. Nous avons un agent qui remplit automatiquement les données du client dans nos contrats Standard. Un agent qui prépare des offres préliminaires sur la base d’un résumé d’entretien de vente. Un intégrateur qui importe la liste de projets Excel d’un client directement dans son environnement FlexiProject. Un assistant qui nous aide à gérer certaines parties de notre site web. Un agent qui extrait les données de Google Search Console pour notre domaine et les transforme en un résumé hebdomadaire lisible. Un agent qui, après les réunions avec les clients, met à jour notre carnet de commandes avec ce que certaines entreprises considèrent comme manquant, afin que les idées de fonctionnalités ne se perdent pas entre un appel et la prochaine session de planification. Et des dizaines d’autres plus petits, des aides à une seule tâche que quelqu’un a construit pour lui-même, qu’il a continué à améliorer et qu’il a finalement partagé avec l’équipe.
Lorsque le même agent est étendu en parallèle
La friction n’est pas venue des agents que nous avons construits une fois et que nous avons oubliés. Elles venaient des agents qui comptaient vraiment. Deux personnes prenaient un agent utile, chacune avait une idée différente sur la façon de l’améliorer et commençait à l’étendre indépendamment. Une semaine plus tard, nous avions deux versions : des invites différentes, des outils différents, des cas de figure différents – et aucun moyen propre de les fusionner. C’était le même problème que les développeurs ont résolu il y a des décennies avec Git : vous ne pouvez pas avoir deux personnes travaillant à partir d’un point de départ commun et l’améliorant dans des directions différentes sans un modèle de ramification. Nous ne pensions tout simplement pas en avoir besoin. Les agents étaient « faciles ». L’expression « gestion de projets d’IA » n’était pas encore entrée dans notre vocabulaire.
Pourquoi le développement d'agents d'IA relève fondamentalement de la gestion de projets informatiques ?
La création d’agents est d’une simplicité enfantine
La première leçon est la plus gênante : il est vraiment facile de créer un agent. Toute personne lisant ceci peut ouvrir un modèle et avoir quelque chose qui fonctionne en moins d’une heure. La démo sera magique. Les trois premiers utilisateurs l’adoreront. Et c’est exactement à ce moment-là que le projet devient difficile, parce que livrer une démo n’est pas livrer un outil sur lequel l’entreprise peut compter. L’écart entre « fonctionne avec les données que j’ai essayées » et « fonctionne avec les données que l’ensemble de l’entreprise lui soumet » est énorme, et le modèle lui-même ne fait rien pour le combler. C’est à cela que sert la gestion des projets d’IA.
Une équipe d’entreprise qui construit des agents d’IA doit apprendre la gestion de projet informatique.
Lorsqu’une équipe non informatique commence à construire un logiciel, et qu’un agent est un logiciel, il hérite de tous les problèmes que les équipes d’ingénieurs ont passé cinquante ans à apprendre à gérer. Les exigences doivent être écrites. L’architecture doit être conçue. Le code, les messages-guides ou les définitions d’outils doivent être partagés. Les tests doivent exister. Les Revues doivent être examinées avant d’être mises en service. Le fait d’omettre l’un de ces éléments ne le fait pas disparaître ; il ne fait qu’avancer le coût dans le temps. La bonne nouvelle, c’est que le manuel existe déjà. Les disciplines qui assurent la réussite des projets informatiques s’appliquent sans changement lorsqu’une équipe commerciale construit des agents. Le seul nouvel ingrédient est l’évaluation – la version spécifique à l’IA des tests.
Essayez FlexiProject !
Le cycle de vie d'un projet d'agent d'intelligence artificielle
1. Analyse initiale – quel est le problème que nous sommes en train de résoudre ?
Tout agent digne de ce nom commence par une phase d’analyse qui n’a rien à voir avec l’IA. Qui va l’utiliser ? Que font-ils aujourd’hui, étape par étape ? Lesquelles de ces étapes sont réellement nuisibles ? À quoi ressemble le « bien fait » – de manière mesurable ? Avant de créer l’agent chargé de préparer les offres, nous avons consigné par écrit la séquence manuelle exacte suivie par l’équipe de vente, indiqué les étapes répétitives et celles qui nécessitaient du discernement, puis nous avons décidé ce que l’agent devait faire et ne pas faire. L’analyse a pris plus de temps que la construction. Ce ratio est normal.
2. Planification – portée, intégrations, branche partagée
La planification est le moment où vous décidez de trois choses : les entrées et les sorties, les intégrations que l’agent touchera et, plus important encore, l’endroit où le travail sera effectué. Si deux personnes doivent contribuer, elles ont besoin d’une définition commune de « principal ». Il peut s’agir d’un document unique contenant les invites canoniques et les définitions des outils, d’un répertoire, d’un dossier de compétences – le format importe moins que l’accord. Choisissez-le dès le premier jour. Décidez de ce que l’agent ne fera pas, écrivez-le et tenez-vous-y ; le scope creep est la raison la plus courante pour laquelle les agents ne peuvent pas être maintenus.
3. Le développement – la partie faussement facile
La construction elle-même est rapide. C’est le piège. Vous écrirez vos messages-guides, brancherez vos outils, exécuterez quelques exemples et aurez l’impression d’avoir terminé à 80 %. Vous en êtes plutôt à 30 %. Les 70 % restants correspondent à tout ce que vous n’avez pas encore testé : les entrées bizarres, les entrées longues, les entrées dans une autre langue, les cas où un outil renvoie un résultat vide, les cas où l’utilisateur change d’avis au milieu de la conversation. Rien de tout cela n’est visible de l’intérieur de la construction.
4. Tester – et tester à nouveau
C’est sur ce point que les agents diffèrent le plus des logiciels classiques et que la plupart des équipes font des économies. Un agent réussit un test aujourd’hui et peut échouer au même test demain parce que vous avez changé une seule ligne dans l’invite ou parce que le modèle sous-jacent a été mis à jour. La discipline dont vous avez besoin est l’évaluation de la régression : un ensemble sauvegardé d’entrées avec les comportements attendus, exécuté automatiquement, ou au moins systématiquement, après chaque changement. Sans cela, vous ne découvrirez les régressions que lorsqu’un utilisateur s’y heurtera.
5. Livraison et remise
Un agent qui n’est jamais officiellement livré est un agent qui devient obsolète dès le premier jour. La livraison implique la rédaction de la documentation destinée à l’utilisateur, la définition de la réussite en production et la mise en place d’un moyen de contrôler si l’agent est toujours utile trois mois plus tard. Nous l’avons appris à nos dépens – voir la section suivante.
MVP, Agile et Scrum dans les projets d'IA
MVP first – commencez par le plus petit agent utile
Chaque agent que nous avons construit et qui a réussi a commencé par être la plus petite version utile de lui-même. Une tâche. Une entrée. Une sortie. Nous avons résisté à la tentation d’ajouter un deuxième cas d’utilisation tant que le premier n’avait pas survécu au contact avec des utilisateurs réels. Les agents qui ont eu des difficultés étaient à l’opposé : ambitieux dès le premier jour, avec trois capacités dont aucune n’a fonctionné jusqu’au bout. Les agents « big-bang » échouent pour les mêmes raisons que les projets logiciels « big-bang » ; le facteur de forme ne change rien aux calculs. Si vous ne retenez qu’une seule règle de cet article, prenez celle-ci : un MVP pour un agent d’intelligence artificielle est suffisamment petit pour qu’une personne puisse le décrire en trois phrases et l’exécuter de bout en bout sur un exemple réel avant la fin de la journée. Tout ce qui suit n’est qu’itération.
Pourquoi l’agile s’adapte naturellement aux agents d’intelligence artificielle.
Les agents sont exceptionnellement bien adaptés au travail agile parce qu’ils sont exceptionnellement imprévisibles. Vous ne pouvez pas spécifier complètement un agent à l’avance de la même manière que vous spécifiez un formulaire de paiement ou un rapport. Vous faites une petite version, vous la regardez fonctionner dans le monde réel, vous voyez où elle échoue, vous corrigez la chose suivante. Essayer de concevoir l’agent parfait sur papier avant de le construire est le moyen le plus rapide de construire le mauvais agent. L’itération n’est pas une préférence en matière de gestion de projet pour l’IA ; c’est une exigence structurelle – le même rythme Planifier, Faire, Contrôler, Agir que Deming a décrit il y a des décennies pour tout processus qui doit être amélioré en permanence, simplement appliqué à des agents dont vous ne pouvez pas entièrement prédire le comportement.
Exécution du travail de l’agent dans les sprints Scrum
Nous traitons chaque agent important comme un petit flux de travail de type Scrum. Il y a une liste de capacités que l’agent pourrait avoir. Chaque sprint en sélectionne un petit nombre. La démo du sprint est l’agent lui-même, exécuté sur des données réelles de l’équipe qui l’utilisera. Si la démo n’est pas convaincante, le travail continue ; la cadence oblige à une véritable conversation entre le constructeur et les utilisateurs au lieu d’une construction silencieuse qui dure des mois.
Les erreurs que nous avons commises
Construire avant d’analyser
Parce que la construction est si rapide, il semble efficace de passer directement à la construction. Ce n’est pas le cas. Les agents que nous avons construits sans analyse claire ont fini par fonctionner techniquement tout en résolvant le mauvais problème ; l’équipe qui les utilisait a été polie à ce sujet pendant un certain temps, puis est retournée tranquillement faire le travail manuellement. Un après-midi d’analyse aurait permis d’économiser une semaine de construction.
Faire confiance au modèle pour trouver la solution
C’est l’erreur la plus fréquente et la plus difficile à désapprendre. Nous pensions que si nous donnions au modèle la tâche à accomplir en termes simples, il concevrait une bonne solution. Souvent, ce n’était pas le cas – non pas parce que le modèle était faible, mais parce que nous n’avions pas fait le travail de conception nous-mêmes. Le modèle ne connaît pas le contexte de votre entreprise, vos données existantes, vos conventions non écrites, le système qui entoure la tâche. Plus vous lui donnez de ces éléments, une véritable analyse, une véritable architecture, la structure que vous voulez qu’il suive, meilleur sera le résultat. Le modèle est excellent dans l’exécution. Il n’est pas votre architecte.
Faire un big-bang au lieu de commencer par un MVP
Chaque fois que nous avons essayé de lancer un agent complet dès le premier jour, le résultat a pris plus de temps à construire, a été plus difficile à déboguer et a été abandonné plus souvent que les petites versions que nous avions développées délibérément. Le big-bang semblait plus rapide. Ce n’était pas le cas.
Deux personnes développent le même agent en parallèle
C’était le moment Git. Deux personnes, le même agent, des idées différentes, des branches différentes dans leurs têtes, pas de « main » partagée. Une semaine plus tard, deux versions qui ne se réconciliaient pas. Nous traitons désormais chaque agent significatif de la même manière que les développeurs traitent le code : une version canonique, un modèle de ramification explicite lorsque plusieurs personnes travaillent dessus, et une étape de fusion explicite. Ou, si les idées divergent vraiment, une décision délibérée de se scinder en deux agents distincts au lieu de prétendre qu’ils ne font qu’un.
Pas de documentation initiale – les utilisateurs ne savaient pas ce que faisait l’agent
Les premiers utilisateurs internes de nos compétences ne cessaient de poser les mêmes questions : que fait cette chose, que dois-je transmettre, à quoi ressemble le résultat, quand dois-je l’utiliser par rapport à la version précédente ? Nous pensions que l’agent était explicite. Ce n’était pas le cas. Nous rédigeons désormais une brève description de chaque agent à l’intention de l’utilisateur au moment de la remise de l’agent – ce qu’il fait, ce qu’il faut lui donner, ce à quoi il faut s’attendre, ce qu’il ne fait pas. Cela ne prend que dix minutes et évite des semaines d’utilisation confuse.
Essayez FlexiProject !
Questions fréquemment posées sur la gestion des projets d'IA
La gestion des projets d’IA est-elle différente de la gestion des projets informatiques ordinaires ?
Les disciplines sont les mêmes : analyse, planification, construction, test, livraison, itération. Les différences se situent dans les phases de construction et de test : les résultats ne sont pas déterministes, le comportement peut dériver lorsque le modèle ou les invites changent, et le « test » devient une « évaluation par rapport à un ensemble de cas sauvegardés ». Tout ce qui entoure ces phases ressemble à un projet informatique normal.
Ai-je besoin d’un outil de gestion de projet pour gérer le développement des agents d’IA ?
Vous avez besoin d’un endroit où chaque agent vit comme un projet : avec un plan, une version actuelle, un propriétaire et un état de livraison. Que cet endroit soit un système de gestion de projet, un wiki ou une structure de dossiers importe moins que le fait d’en avoir un. Pour les équipes qui gèrent de nombreux agents en parallèle, un véritable système de gestion de projet est rapidement rentabilisé.
Quelle doit être la taille d’un agent MVP ?
Suffisamment petit pour qu’une personne puisse le décrire en trois phrases et l’exécuter de bout en bout sur un exemple réel avant la fin de la journée. Si vous ne pouvez pas le faire, le champ d’application est trop vaste et le MVP est quelque chose de plus étroit à l’intérieur de celui-ci.
Comment empêcher deux personnes de construire le même agent en parallèle ?
Vous n’empêchez pas deux personnes de contribuer – vous indiquez explicitement où se trouve la version canonique, qui est propriétaire de la fusion et quand des idées divergentes doivent devenir une fourche délibérée dans deux agents distincts. La leçon tirée de l’ingénierie logicielle s’applique d’une manière univoque : une branche partagée, avec un processus de fusion convenu.
Quand un agent devient-il héritier ?
Le moment où personne n’est chargé d’évaluer s’il est toujours utile. Un agent que personne ne contrôle se dégrade tranquillement, le monde qui l’entoure change, les données d’entrée évoluent, le modèle sous-jacent est remplacé et, un jour, il se trompe et personne ne s’en aperçoit. L’héritage n’est pas un âge, c’est un état de négligence.
Conclusion
La partie excitante de la construction d’agents d’IA, le modèle, les invites, le moment où une démo fonctionne pour la première fois, est la plus petite fraction du travail. Les parties non passionnantes sont celles qui transforment une démo en un outil sur lequel toute l’entreprise peut compter : une analyse claire, un véritable plan, une branche partagée, des tests de régression, de la documentation et un rythme d’itération qui permet à l’agent de rester utile longtemps après la livraison de la première version. Rien de tout cela n’est exotique. Il s’agit exactement de la discipline qui assure la réussite des projets informatiques depuis des décennies, appliquée sans dilution à un type de logiciel légèrement plus récent. Les équipes qui adoptent cette discipline très tôt se retrouvent avec des agents en qui elles ont confiance. Les équipes qui l’ignorent finissent par reconstruire deux fois le même agent. Traiter chaque agent comme un véritable projet, avec un plan que vous pouvez établir, revoir et améliorer, c’est ce que la gestion de projet d’IA signifie en pratique. C’est ce que nous faisons dans FlexiProject, où chaque agent reçoit son propre dossier de projet avec un plan d’action clairement écrit ; quel que soit le système que vous choisissez, traitez chaque agent comme un projet, et non comme une expérience.
AUTEUR
Dominik Wrzosek
General Manager at FlexiProject
![Qu’est-ce qu’un diagramme de Gantt et comment en créer un ? [EXEMPLE]](https://flexi-project.com/wp-content/uploads/2024/04/What-is-Gantt-chart-e1714048900401.png)
