Quel agent IA choisir pour vos projets ?

La semaine dernière, j'ai vu quelqu'un demander à son agent frontend de "créer un super prompt pour générer des images". L'agent l'a fait. Mal. Il a produit ce qu'un développeur frontend écrirait : un truc en forme de composant, vaguement visuel, sans rien de ce qu'un prompt engineer sait sur les termes d'éclairage, le vocabulaire caméra et les negative prompts.

Personne n'a rien remarqué, parce que l'échec est silencieux. L'agent ne dit pas "ce n'est pas mon métier". Il fait juste une version médiocre du métier d'un autre.

C'est le vrai coût du mauvais choix d'agent. Pas des erreurs. De la médiocrité qui ressemble à du travail rendu.

La persona, c'est le produit

Un agent IA, c'est un modèle plus un system prompt. Même modèle, system prompt différent, résultats différents. Tout le truc tient là, et ce n'est pas un petit truc.

Un agent QA ne "cherche pas plus fort les bugs". Sa persona lui dit de se méfier du happy path, d'énumérer les cas limites et d'écrire la reproduction avant le fix. Un agent Sécurité lit le même code d'authentification que ton agent fullstack et voit une fixation de session là où le fullstack voit un login qui marche. Les 14 rôles intégrés d'AgentsRoom existent parce que ces cadrages changent réellement ce qui sort du même modèle.

Donc "quel agent utiliser" n'est pas cosmétique. Ça décide quels réflexes sont allumés pendant que ta tâche se fait.

Matche la tâche, pas l'habitude

L'habitude : tout envoyer à l'agent déjà ouvert. Souvent un dev fullstack, parce que c'est lui que tu as ouvert lundi.

Le match : lire ta tâche et nommer la spécialité à laquelle elle appartient.

Des exemples réels, avec qui devrait vraiment les prendre :

• "Rédiger l'article de lancement" : un Expert Marketing, pas ton dev fullstack. Le positionnement et le copy sont une spécialité, et ça se voit en deux paragraphes.
• "Ce test échoue une fois sur cinq" : un agent QA. Les tests instables sont une discipline : isolation, timing, fixtures. Un agent dev va souvent relancer jusqu'au vert.
• "Durcir le flux de connexion" : un agent Sécurité. Il vérifiera la rotation des tokens, l'invalidation de session et le rate limiting sans qu'on lui demande.
• "Créer des prompts pour générer des images" : un Prompt Engineer du catalogue. C'est exactement le job de l'intro, et exactement l'agent qu'il fallait.
• "Le dashboard est lent" : un agent Backend pour les requêtes, un agent Frontend pour le rendu. Si tu ne sais pas encore quel côté est coupable, c'est d'abord une tâche de profiling.

Si la tâche nomme un livrable qu'un spécialiste du monde réel posséderait, donne-la à ce spécialiste. Tu en as 260+ dans le catalogue, plus tes propres agents custom. Utiliser un généraliste pour tout, c'est payer un banc de touche et faire jouer un seul joueur.

Quand tu ne sais pas : dis-le

Voilà la partie qui a changé ma façon de bosser. Tu n'es pas obligé de savoir.

AgentsRoom a un conseiller Suggestions d'agent pour exactement ce moment. Clique l'étincelle à côté de la recherche d'agents, tape la tâche comme tu la dirais à voix haute ("rédiger l'article de lancement", "auditer le flux de connexion"), et il répond avec l'agent le mieux placé pour le job, une raison en une ligne, et deux alternatives. Les agents déjà libres dans ta room sont signalés : le conseiller te dit de réutiliser avant de te dire d'ajouter.

Ensuite un clic assigne la tâche : l'agent est ajouté si besoin, son terminal s'ouvre, et le texte exact que tu as tapé atterrit dans le composer en brouillon. Tu as déjà décrit la tâche une fois. Cette description devient le premier prompt.

La règle de classement compte : l'adéquation d'abord, la commodité ensuite. Le conseiller ne refilera pas ton job de prompts d'images au dev frontend juste parce que le dev frontend est libre. On a réglé ça sur de vrais ratés.

Réutilise avant d'ajouter

Une room avec douze agents à moitié utilisés est un échec en soi. Deux règles la gardent saine.

Agent libre qui colle : réutilise-le. Un agent sans tâche en cours et avec la bonne spécialité est le meilleur choix, à chaque fois. Le conseiller applique cette règle automatiquement.

Bonne spécialité mais occupé : ajoutes-en un frais au lieu de faire la queue. Les agents sont des sièges pas chers. Attendre que ton unique agent QA finisse pendant que trois bugs s'empilent, c'est un goulot d'étranglement que tu as inventé.

Et quand une tâche change de nature en cours de session ("en fait, écris maintenant la doc de ce que tu as construit"), tu n'as même pas besoin d'un nouvel agent : l'Agent Morphing transforme l'agent en cours en un autre spécialiste, contexte intact.

Une tâche, plusieurs spécialistes

Certaines tâches ne sont pas une seule spécialité. "Livrer la feature paiements", c'est un job backend, puis un job QA, puis peut-être une revue sécurité. Choisir un seul agent pour ça, c'est décider en silence que les deux autres spécialités n'auront pas lieu.

C'est à ça que servent les Équipes : chaîner des agents pour que le travail circule du dev à la QA à la revue, chaque siège tenu par la bonne persona. La question du choix devient "qui est dans le pipeline" au lieu de "qui prend tout".

La version en cinq secondes

Nomme la spécialité à laquelle la tâche appartient. Si un agent libre de ta room la possède, prends-le. Sinon, ajoute le rôle ou l'expert du catalogue qui la possède. Si tu ne sais pas nommer la spécialité, décris la tâche et laisse le conseiller la nommer.

Et une fois que le bon agent a le job, assure-toi qu'il ne réapprenne pas ta codebase de zéro à chaque session : ça, c'est un problème de mémoire, et c'est le prochain truc qui vaut le coup d'être réglé.