Une marketplace d’agents IA réduit le temps de découverte, mais la qualité d’une fiche ne garantit pas l’adéquation au processus de votre PME. Les filtres doivent servir à constituer une liste courte, puis chaque agent est testé sur ses données autorisées, ses actions et sa reprise humaine.
Les critères les plus utiles décrivent le fonctionnement observable, pas une promesse générale d’autonomie.
Filtrer par tâche et sortie
Cherchez le verbe : qualifier, répondre, classer, planifier, rédiger ou mettre à jour. Précisez la sortie attendue : fiche, brouillon, rendez-vous, résumé ou alerte.
Une catégorie « agent RH » peut contenir un assistant de recherche documentaire et un agent de planification. Ils ne reçoivent pas les mêmes données ni les mêmes droits.
Utilisez le secteur seulement lorsqu’il change les connaissances, les intégrations ou les contraintes. Un label sectoriel sans exemple de flux apporte peu.
Lire les preuves et la date
La fiche doit distinguer les fonctions annoncées, les tests de la marketplace et les avis utilisateurs. Cherchez le scénario, la date, la langue et la version.
Une vidéo montre l’interface, mais demandez les sorties, les journaux et les erreurs. Un cas client n’est utile que si sa source et son contexte sont vérifiables ; n’extrapolez pas un résultat à votre entreprise.
Vérifiez les relations commerciales et le processus de classement. La transparence permet d’utiliser la recommandation comme une information, pas comme une validation finale.
Examiner langues et conversations
Pour un agent vocal, support ou commercial, testez la langue réelle, les accents, les noms propres et le vocabulaire. Une mention « français » ne décrit pas la qualité d’une conversation métier.
Introduisez une correction, une interruption et une demande hors sujet. L’agent doit conserver le contexte et savoir passer la main.
Pour un texte, contrôlez les caractères, formats de date et conventions locales. La traduction d’une interface ne garantit pas l’adaptation des connaissances.
Vérifier intégrations et permissions
Demandez quels objets et actions sont pris en charge dans chaque connecteur. Une intégration CRM peut lire les contacts sans créer de tâche, ou demander des droits plus larges que nécessaire.
Cherchez la possibilité d’utiliser un compte de service, de limiter les rôles et de tester en environnement isolé. Examinez le comportement en cas de panne, doublon ou donnée inconnue.
Ne connectez pas un système réel pour une première démonstration. Un simulateur ou une base fictive suffit à valider le flux.
Comparer contrôle et administration
L’agent permet-il une validation avant action, une reprise, une suspension et un retour en arrière ? Les utilisateurs voient-ils les sources et l’incertitude ? Les administrateurs peuvent-ils gérer les versions et les journaux ?
Examinez la maintenance des connaissances et consignes. Qui peut les modifier et comment une correction est-elle testée ? Un produit prêt à lancer exige tout de même une responsabilité interne.
Préparez la sortie : export, suppression, révocation des accès et remplacement. Une marketplace facilite l’entrée ; elle doit aussi documenter la relation directe avec le fournisseur.
Construire une liste courte explicable
Conservez quelques agents qui couvrent des approches différentes. Pour chacun, notez l’usage, les prérequis, la preuve, les limites et la question ouverte.
Refusez un outil si l’information critique reste absente ou si le droit demandé ne correspond pas à la tâche. Demandez une démonstration personnalisée pour les finalistes.
Contacter directement l’éditeur
La marketplace présente et compare, mais l’éditeur doit répondre sur la configuration, les données, le support et la continuité. Envoyez les mêmes questions aux finalistes et demandez des documents actuels. Une réponse commerciale orale n’a pas le même statut qu’une condition écrite.
Profitez de cet échange pour identifier l’équipe qui accompagnera le pilote. La personne présente pendant la vente ne sera pas toujours celle qui configure ou traite un incident. Clarifiez les canaux et responsabilités avant de connecter un outil.
Préparer un dossier de pilote
Rassemblez le scénario, les données fictives, les critères, les permissions, la durée et la sortie. Faites valider le dossier par les rôles internes appropriés. Une liste courte sans protocole conduit simplement à trois démos différentes.
Ajoutez les conditions d’arrêt et la reprise manuelle. Le pilote doit pouvoir se terminer sans laisser de connecteur actif ni de tâche en attente. Demandez à chaque éditeur de confirmer qu’il peut respecter ce dispositif avant de planifier la session.
Vérifier une fiche avec cinq questions
Pour chaque agent présélectionné, posez cinq questions dans la même forme. Quelle entrée accepte-t-il réellement ? Quelle sortie produit-il ? Quelle source peut-il citer ? Quelle action peut-il déclencher ? Comment un humain reprend-il la main ? Les réponses doivent être concrètes et reliées à une page de documentation ou à une observation. Une phrase comme « s’intègre à votre environnement » ne précise ni l’objet lu, ni le droit requis, ni la trace laissée.
Demandez également la date de la capacité annoncée. Une fiche peut rester visible après une évolution du connecteur ou du modèle. Notez ce qui a été confirmé, ce qui dépend d’une configuration et ce qui doit être testé. Cette petite discipline évite de faire passer une promesse de catalogue pour une preuve opérationnelle.
Lire les limites comme des critères de choix
Les limites sont souvent plus utiles que la liste des fonctionnalités. Cherchez les langues réellement testées, les formats non pris en charge, les délais de mise à jour des sources, les restrictions d’export et les conditions d’arrêt. Une solution peut être pertinente pour un flux textuel et inadaptée à des pièces jointes ou à des échanges multilingues.
Classez ces limites selon leur conséquence. Certaines demandent une consigne ou un contrôle supplémentaire. D’autres imposent une étape manuelle. Les dernières rendent le cas d’usage impossible dans son périmètre actuel. Écrivez la décision avec cette distinction afin que la liste courte reste compréhensible pour une autre équipe.
Organiser les démonstrations de manière comparable
Envoyez à chaque éditeur un même dossier fictif : une demande normale, une demande ambiguë, une source contradictoire et une demande hors périmètre. Demandez la sortie attendue, les journaux disponibles et les permissions nécessaires. Ne donnez pas uniquement un exemple parfaitement préparé ; il ne révèle pas la capacité d’abstention.
Faites observer la configuration par une personne métier et une personne technique. La première vérifie le vocabulaire, le parcours et la reprise. La seconde vérifie l’identité, les droits, le stockage, les versions et la suspension. Leur compte rendu doit rester séparé avant la synthèse pour éviter qu’un avis d’interface masque une restriction importante.
Conserver une shortlist réversible
Une shortlist n’est pas un classement définitif. Pour chaque option, gardez un motif d’inclusion, une question non résolue, un test à exécuter et une condition de retrait. Une option peut sortir si elle ne permet pas de distinguer une suggestion d’une donnée confirmée, si l’export manque ou si la reprise n’est pas transmise avec le contexte.
Préparez aussi le chemin de sortie. Qui récupère les données ? Comment révoquer les accès ? Où conserver les consignes et les règles métier ? Un choix raisonnable reste explicable même si l’éditeur, le connecteur ou le périmètre change.
Lire la fiche technique sans confondre les niveaux
Séparez le modèle utilisé, l’orchestrateur, les connecteurs, l’interface et le service d’accompagnement. Une marketplace peut présenter une expérience unique alors que les données passent par plusieurs composants. Demandez quel élément conserve la mémoire, quel élément appelle l’outil et quel élément produit le journal. Cette décomposition rend les questions de responsabilité plus précises.
Cherchez la différence entre une capacité native et une capacité obtenue par une automatisation externe. Dans le second cas, le comportement dépend aussi du déclencheur, des filtres et des erreurs de la chaîne. Testez le cas où le connecteur renvoie un résultat vide, lent ou ambigu. La page produit ne suffit pas à conclure que le flux est robuste.
Vérifiez enfin le mode de mise à jour. Un changement de modèle, de connecteur ou de consigne peut modifier les sorties sans que le nom de l’agent change. La shortlist doit donc conserver la version observée, la date du test et la question qui devra être rejouée après une évolution.
Examiner l’administration quotidienne
Demandez qui crée les utilisateurs, qui modifie les instructions et qui approuve une nouvelle source. Une équipe peut être ravie de l’installation puis perdre la maîtrise lorsque la seule personne qui connaît la configuration quitte le projet. La marketplace doit être évaluée sur les gestes de maintenance, pas uniquement sur le premier branchement.
Testez la révocation d’un accès, le remplacement d’une source et la suspension d’un agent. Vérifiez la présence d’un historique des versions et la possibilité de distinguer un changement de contenu d’un changement de comportement. Si la procédure nécessite une intervention manuelle du fournisseur, inscrivez le délai de réponse comme une dépendance de projet, sans promettre de résultat avant vérification.
Construisez un tableau de responsabilités. Le métier valide la réponse, la donnée vérifie la source, la technique contrôle l’accès et la personne en charge de la sécurité examine les événements sensibles. Cette répartition transforme la fiche de marketplace en support de décision partagé.
Transformer la shortlist en décision
Avant de retenir une option, faites relire la fiche par un utilisateur qui n’a pas assisté aux démonstrations. Il doit pouvoir expliquer la tâche, le test, la limite et la condition d’arrêt. S’il ne peut répéter que des adjectifs comme « simple », « autonome » ou « intelligent », la preuve est insuffisante.
Écrivez la conclusion en trois parties : ce qui est vérifié, ce qui doit encore être démontré et ce qui est exclu du périmètre. Ajoutez les liens vers la source de l’information et la date de la dernière vérification. Une décision explicable résiste mieux aux changements de personne et de fournisseur.
Si aucune option ne satisfait les exigences, gardez la conclusion « poursuivre la préparation » ou « ne pas ouvrir ce flux ». Une marketplace est un outil d’exploration. Elle ne transforme pas une promesse en validation et ne dispense pas d’un test avec les équipes qui porteront la reprise.
Utiliser une fiche de preuve
Pour chaque capacité, inscrivez la question posée, la réponse de l’éditeur, le lien consulté, la date, la configuration utilisée et le résultat du test. Indiquez si la preuve vient d’une documentation, d’une démonstration ou d’une observation dans un environnement fictif. Cette granularité empêche une seule réponse générale de couvrir des fonctions différentes.
Ajoutez une colonne pour les limites et une autre pour les propriétaires. Une capacité peut être disponible mais nécessiter une source tenue à jour par l’entreprise, une validation par le métier ou une permission administrée par la technique. La fiche doit montrer ces conditions au lieu de les laisser dans des notes dispersées.
Tester l’export et la suppression
La shortlist doit inclure un scénario de sortie. Demandez comment récupérer les consignes, les sources, les journaux et les résultats nécessaires à la continuité. Testez la suspension d’un connecteur puis vérifiez quelles données restent visibles dans l’interface.
Un export qui produit un fichier illisible ou incomplet ne répond pas au besoin de réversibilité. Faites relire l’export par l’équipe qui devrait reprendre le processus. Elle doit comprendre les identifiants et pouvoir retrouver les décisions sans dépendre de la personne qui a installé l’agent.
Évaluer la documentation après installation
Une bonne page produit peut cacher une documentation opérationnelle pauvre. Cherchez les guides d’erreur, les procédures de versionnage, les journaux, les rôles et les limites de connecteurs. Demandez si ces documents sont accessibles à l’équipe qui maintient le flux, pas seulement à un administrateur central.
Testez une petite modification de source et une petite modification de consigne. Vérifiez si la marketplace expose l’historique, la différence entre versions et la possibilité de revenir en arrière. Cette observation complète la comparaison des fonctionnalités.
Fermer la boucle de décision
Lorsque la shortlist est prête, organisez une revue avec les personnes qui porteront le quotidien. Lisez les critères éliminatoires, les questions non résolues et les conditions du pilote. Une option ne doit pas être retenue simplement parce qu’elle est la plus visible ou la mieux présentée.
Rédigez une conclusion courte, puis joignez la fiche de preuve. La conclusion change si une capacité importante reste seulement déclarée. Cette transparence maintient la distinction entre exploration, test et décision.
La grille de sortie d’une marketplace
Avant de fermer l’exploration, vérifiez que l’option retenue possède un scénario de test, une source documentée, une permission minimale, un journal lisible, une reprise humaine, une procédure de suspension et un responsable interne. Si l’un de ces points reste inconnu, indiquez-le comme condition et ne le remplacez pas par une appréciation de l’interface.
La shortlist doit pouvoir être relue plus tard. Conservez la version de la fiche, la date du test, les questions posées et les réponses obtenues. Une capacité évolutive doit être rejouée sur les cas principaux après changement.
Enfin, expliquez pourquoi les autres options n’ont pas été retenues pour ce parcours précis. Cette justification évite de recommencer une exploration identique et rappelle qu’une option écartée peut convenir à une autre intention.
La fiche de shortlist doit également indiquer le prochain test, le propriétaire et la preuve attendue. Sans ces trois éléments, la marketplace reste une liste de liens et non un outil de décision.
Une shortlist terminée doit pouvoir être transformée en protocole de pilote sans repartir de zéro : cas fictifs, données autorisées, droits, reprise, mesure et procédure de sortie. Si elle ne contient que des noms et des fonctionnalités, elle n’a pas encore répondu à l’intention de sélection.
Faites relire ce protocole par l’équipe qui devra utiliser l’agent. Si elle ne peut pas identifier la source, la limite et la personne qui reprend, retournez à la phase de preuve. La marketplace n’est un bon point de départ que lorsque la décision peut être testée.
La sélection finale doit indiquer le motif d’inclusion, la question restante, le cas de test, le propriétaire et la condition de retrait. Elle devient ainsi une décision révisable plutôt qu’un annuaire de capacités.
Ajoutez une date de vérification des capacités qui peuvent évoluer et une personne chargée de rejouer le cas. Lorsque la réponse d’un éditeur reste générale, transformez-la en question de recette. La marketplace sert alors à préparer une preuve, pas à la remplacer.
Exemple de lecture d’une fiche de marketplace
Une fiche peut annoncer un agent « connecté au CRM ». Cette mention ne répond pas encore à la question utile. Le lecteur doit demander quels objets sont lus, quels objets peuvent être créés, quelles permissions sont nécessaires, comment les doublons sont traités et quel journal reste disponible après une action.
Dans une shortlist, inscrivez donc : capacité déclarée, preuve observée, condition de test et limite. Par exemple, une création de tâche peut être observée dans un environnement fictif, tandis que la fusion de contacts reste interdite. L’option reste intéressante pour préparer une file de travail, mais pas pour modifier une base sans validation.
Ce format transforme une page de catalogue en hypothèse contrôlable. Il aide l’équipe à comparer les promesses sur le même niveau de détail et à écarter les capacités qui ne correspondent pas au processus visé.
Revue de maintenance avant choix
Demandez comment une équipe remplace une source, retire un utilisateur, consulte une erreur et restaure une version. Faites réaliser l’un de ces gestes pendant le test. Une capacité qui ne peut être maintenue sans intervention opaque n’est pas équivalente à une capacité que l’entreprise peut gouverner elle-même.
Notez les responsabilités dans le dossier de pilote : qui est propriétaire de la connaissance, qui gère les accès, qui surveille les incidents et qui valide les changements. Cette préparation évite qu’un bon résultat de démonstration devienne une dépendance quotidienne non documentée.
Décider à partir de preuves comparables
Rassemblez les réponses des éditeurs dans une même fiche : entrée testée, source utilisée, action observée, droit nécessaire, journal disponible, arrêt et reprise. Une cellule vide reste une information utile : elle indique qu’une capacité n’a pas été observée ou que la réponse doit être vérifiée pendant le pilote.
La décision finale ne choisit pas « le meilleur agent ». Elle retient une option pour un parcours et un périmètre précis, avec un test restant et une condition de retrait. Cette formulation permet de revenir sur la shortlist lorsque les données, les outils ou les responsabilités changent.
Compte rendu de shortlist
Le compte rendu indique l’option retenue pour le pilote, les options écartées, les preuves collectées, les questions ouvertes et les personnes responsables. Il ne remplace pas une recette, mais évite de recommencer les mêmes démonstrations lorsque l’équipe change ou que le besoin évolue.
Relisez ce document avant tout élargissement. Une nouvelle action ou une nouvelle source constitue un nouveau point de décision, même si elle apparaît dans la même fiche de marketplace.
Lire une fiche fournisseur comme une hypothèse à tester
Une fiche de marketplace décrit souvent un périmètre séduisant ; elle ne remplace pas la preuve d’un comportement dans votre environnement. Lors de la lecture, séparez ce qui est annoncé de ce que vous pouvez vérifier pendant une démonstration. Relevez les données demandées, les outils auxquels l’agent souhaite se connecter, les actions qu’il peut préparer et les conditions dans lesquelles il s’arrête. Une phrase vague comme « s’intègre à votre CRM » doit devenir une question testable : quels objets sont lus, quels champs peuvent être écrits, qui valide l’autorisation et comment l’équipe récupère l’historique.
Créez une colonne « preuve manquante » à côté de chaque critère. Vous pouvez y inscrire une documentation à obtenir, un cas à rejouer, un rôle à interroger ou une limite que le fournisseur ne documente pas. Cette colonne empêche la shortlist de devenir une liste de promesses reformulées. Elle aide aussi à comparer des options qui ne proposent pas le même niveau de détail : une information absente n’est ni un avantage ni une preuve de compatibilité, c’est un travail de vérification encore ouvert.
Pour finir, demandez à la personne qui utilisera le flux de présenter la fiche à un collègue non impliqué. Elle doit expliquer ce que l’agent ferait le premier jour, ce qu’il ne ferait pas, comment interrompre une action et où se trouve la trace. Si elle ne peut répondre qu’en renvoyant vers une démonstration commerciale, la décision est prématurée. Cette lecture transforme le marketplace en point de départ pour une recette locale, sans confondre une description de catalogue avec l’adoption d’un outil dans une PME.
La fiche de décision reste ainsi utile lorsque l’éditeur modifie son catalogue ou que l’équipe change. Elle contient les preuves attendues, les limites retenues et les questions qui doivent être reposées avant tout nouveau périmètre.
Questions fréquentes
Une fiche « vérifiée » suffit-elle ?
Demandez ce que la vérification couvre et à quelle date. Elle peut confirmer l’identité ou une fonction sans valider votre usage et vos données.
Comment comparer des avis contradictoires ?
Cherchez le cas, la version et le contexte. Transformez les divergences en scénarios à tester plutôt qu’en moyenne abstraite.
Peut-on acheter directement depuis une marketplace ?
Avant tout engagement, vérifiez le fournisseur, les conditions, les données, le support et les validations internes. La marketplace ne remplace pas votre processus d’achat.
Utiliser la marketplace comme point de départ
Contactez Agents-IA.pro pour filtrer les agents par tâche, langue, intégration et niveau de contrôle avant un pilote.
À lire ensuite
Pour compléter cette étape, consultez Agent IA support client : préparer les connaissances.
Pour vérifier le point suivant, poursuivez avec Choisir un agent IA adapté au métier de votre PME.
Pour replacer cette décision dans l’ensemble du dossier, lisez Comparer deux agents IA sans suivre la démo parfaite.
Pour éviter une analyse isolée, rapprochez ce guide de Déployer un agent IA commercial avec garde-fous.
Sources de référence
Ces références permettent de vérifier les règles, les méthodes et les limites évoquées dans l’article.
Pour contrôler les éléments factuels, consultez EUR-Lex — règlement européen sur l’IA : Cadre officiel européen pour les obligations, les risques et la gouvernance des systèmes d’IA.
Pour contrôler les éléments factuels, consultez NIST — AI Risk Management Framework : Cadre public de référence pour gouverner, mesurer et maîtriser les risques liés à l’IA.
Pour contrôler les éléments factuels, consultez CNIL — intelligence artificielle : Recommandations françaises sur l’IA, les données personnelles et les droits des personnes.