Un agent IA peut-il vraiment gérer votre communauté ?
Oui pour la mécanique, non pour les décisions difficiles à inverser — et « garder un humain dans la boucle » n'est pas la solution non plus. Le bug des 8 000 bannissements de Discord montre pourquoi.
Par Mathis Grosjean
Sur cette page
Réponse courte : un agent IA peut aujourd'hui gérer la mécanique d'une communauté — rédiger, planifier, lire, résumer, orienter et répondre aux questions qui ont déjà une réponse documentée. Il ne faut pas lui confier des décisions dont les échecs sont coûteux et difficiles à inverser, et la raison n'est pas que les modèles sont stupides. C'est qu'ils sont peu fiables d'une manière précise et mesurée, et que l'étape de relecture humaine sur laquelle on compte comme filet de sécurité est elle-même un logiciel qui peut défaillir. La troisième partie est celle qu'on oublie généralement : « toujours garder un humain dans la boucle » n'est pas la correction non plus. La bonne question est : quelles décisions, à quel niveau de confiance, avec quel recours.
Divulgation : Zealy publie cette page et Zealy vend le produit dont il est question. Zealy est une plateforme de communautés et de quêtes, Zealy fournit un serveur MCP qui permet à un agent IA d'administrer une communauté Zealy, et Zealy fournit un évaluateur IA qui tranche les demandes de quêtes. Les trois apparaissent ci-dessous, y compris l'endroit où deux d'entre eux se contredisent et les deux endroits où la conception d'un concurrent est meilleure que la nôtre.
Dernière vérification : 18 août 2026.
Que peut réellement faire un agent IA dans une communauté aujourd'hui ?
Un agent IA peut accomplir de façon fiable la mécanique : rédiger des publications et des réponses, les planifier, lire un canal et le résumer, orienter un signalement vers la bonne personne et répondre aux questions qui ont déjà une réponse documentée. Ce sont des tâches où une sortie erronée est visible, peu coûteuse et facile à corriger avant que quiconque ne soit lésé.
Cette liste n'est pas anodine. L'essentiel du travail communautaire est mécanique, et la plupart des équipes communautaires sont en retard sur ce point. Si un agent rédige votre récapitulatif hebdomadaire et qu'une personne passe quatre minutes à le corriger au lieu de quarante à l'écrire, c'est un vrai gain avec un risque limité.
Nous écrivons cet article parce que la question reçoit de mauvaises réponses. En recherchant can ai run my community le 18 août 2026, tous les résultats que nous avons obtenus étaient un blog d'éditeur ou une page produit d'éditeur — heightsplatform.com, mightynetworks.com, social.plus, circle.so, socialglow.com, aismartventures.com. Aucun des résultats que nous avons obtenus ne répondait à la question par « non » ou « en partie ». Chacun la reformulait en liste de fonctionnalités. C'est une observation sur les résultats obtenus un jour donné, pas une affirmation sur tout ce qui a jamais été écrit.
Les éditeurs de la catégorie sont plus honnêtes que leurs pages d'accueil ne le suggèrent. Le guide de Sprout Social pour créer des agents IA pour les réseaux sociaux, par McCall Lanman, publié le 16 avril 2026, définit la catégorie par l'absence d'une personne : « Un agent IA est un programme logiciel qui utilise un grand modèle de langage (LLM) comme cerveau pour accomplir des tâches de manière autonome, prendre des décisions et interagir avec des outils externes — sans qu'un humain dirige chaque étape. » Plus bas sur la même page, il vous invite à remettre la personne : « Flux d'approbation : acheminez les réponses sensibles vers un responsable humain avant leur envoi — c'est ce qu'on appelle le human-in-the-loop. » Et clairement : « Sans garde-fous, même un agent bien conçu produit des sorties hors marque ou nuisibles. »
Ce n'est pas de l'hypocrisie. C'est la difficulté réelle de la catégorie qui transparaît à travers une page marketing, et cela mérite d'être dit avec bienveillance. Si vous voulez que le terme lui-même soit correctement défini, notre pilier sur le marketing agentique le juge à l'aune de la mécanique plutôt que de l'ambition.
Pourquoi la vraie limite est l'irrégularité, pas la capacité
Le problème quand on confie un jugement à un agent n'est pas que les modèles sont stupides. C'est qu'ils sont inconstants, et l'inconstance est plus difficile à gérer qu'une faiblesse connue. La recherche sur les conversations multi-tours situe l'essentiel de la dégradation dans la variance plutôt que dans la capacité brute.
L'article est « LLMs Get Lost In Multi-Turn Conversation » de Philippe Laban, Hiroaki Hayashi, Yingbo Zhou et Jennifer Neville, arXiv:2505.06120, soumis le 9 mai 2025. Son résumé indique que « tous les meilleurs LLM à poids ouverts et fermés que nous testons affichent des performances nettement inférieures en conversation multi-tours qu'en simple tour, avec une baisse moyenne de 39 % sur six tâches de génération. »
La phrase qui compte davantage est la suivante : « L'analyse de plus de 200 000 conversations simulées décompose la dégradation des performances en deux composantes : une perte mineure d'aptitude et une augmentation significative de l'irrégularité. » Et le mode de défaillance a une forme — « lorsqu'un LLM fait fausse route dans une conversation, il se perd et ne se rattrape pas ».
Lisez les réserves avant d'utiliser ce 39 % où que ce soit. Il s'agissait de conversations simulées sur six tâches de génération, mesurées sur des modèles de 2025, et 39 % est une moyenne sur ces tâches, pas une propriété d'un produit que vous pourriez acheter aujourd'hui. Les modèles se sont améliorés depuis. La conclusion durable n'est pas le chiffre, c'est la décomposition.
Voici pourquoi la décomposition constitue tout l'argument. Un outil qui n'est simplement pas encore assez bon est un problème d'ordonnancement : on attend, ou on réduit la tâche. Un outil qui a raison en moyenne et se trompe de façon imprévisible est un problème de gestion, et c'en est un autre. On ne peut pas y remédier en vérifiant les cas difficiles, car on ne sait pas à l'avance quel cas était le difficile. Le travail communautaire est multi-tours par nature — un membre demande, clarifie, objecte, ajoute du contexte trois messages plus tard — ce qui est exactement le cadre mesuré par l'article.
L'humain dans la boucle de Discord était un logiciel, et il avait un bug
Discord a publié, au présent, qu'un membre de son équipe Trust & Safety examine toujours le contenu signalé avant toute action. Un bug a tout de même banni plus de 8 000 comptes. L'humain dans la boucle était un chemin de code, et les chemins de code échouent comme un logiciel, pas comme des personnes.
TechCrunch l'a rapporté le 7 juillet 2026, dans un article de Lauren Forristal intitulé « Discord admet qu'un bug de modération par IA a banni à tort des utilisateurs pour des images inoffensives ». L'essentiel : « Discord a reconnu qu'un bug dans son système de modération par IA a banni à tort plus de 8 000 utilisateurs au cours des deux derniers mois, après que des images inoffensives — notamment des feuilles de calcul, des échiquiers, des textures de jeu, ainsi que des fonds transparents blancs et gris — ont été signalées à tort comme contenu nuisible. »
L'ampleur mérite d'être lue précisément plutôt qu'arrondie. « L'entreprise a confirmé que le problème affectait des comptes depuis mai, avec 200 utilisateurs supplémentaires bannis pendant le week-end avant que son équipe n'identifie et ne corrige le problème. Tous les comptes concernés sont actuellement en cours de restauration. »
Vient maintenant la partie qui change la façon dont vous devriez envisager cela. Le compte de support de Discord lui-même, cité par TechCrunch depuis son fil du 7 juillet 2026, décrivait la conception : « Nos systèmes signalent le contenu en le comparant à du matériel nuisible connu. Ce type de correspondance par similarité peut produire des faux positifs, c'est pourquoi un membre de notre équipe Trust & Safety examine toujours le contenu signalé avant toute action. »
Et le résumé de TechCrunch sur ce qui s'est passé : « Un modérateur humain examine le contenu, mais un bug a fait que le système a immédiatement banni les comptes concernés. »
Les deux sont vrais en même temps. L'étape de révision était conçue, documentée et décrite publiquement au présent — et elle ne s'est pas exécutée. Discord n'a pas menti, et cet article ne soutient pas qu'il l'a fait. Le point est plus étroit et plus inconfortable : un humain dans la boucle est un logiciel et échoue comme tel. C'est un conditionnel, une file d'attente, un appel de service, un feature flag. Chacun d'eux peut être erroné, et quand l'un l'est, la propriété de sûreté sur laquelle vous comptiez cesse discrètement d'exister tandis que le schéma d'architecture l'affiche toujours.
Remarquez aussi quelles étaient les entrées défaillantes. Des feuilles de calcul. Des échiquiers. Des fonds transparents gris. Rien dans cette liste ne ressemble à un cas limite pour lequel quiconque aurait écrit un test, ce qui est la condition ordinaire d'un système de correspondance par similarité confronté au monde réel.
Si votre seule assurance envers vos membres est « une personne vérifie », vous n'avez pas formulé une affirmation sur des personnes. Vous avez formulé une affirmation sur un chemin de code, et vous devriez pouvoir dire quand il s'est exécuté pour la dernière fois.
Pourquoi « toujours garder un humain dans la boucle » n'est pas non plus la leçon
La correction bien propre au battage des fournisseurs consiste à dire qu'une personne doit tout approuver. Le Digital Trust & Safety Partnership, qui écrit pour les entreprises pratiquant cela à grande échelle, ne le dit pas. Il rapporte que l'application automatisée sans révision humaine est courante lorsque la confiance est élevée, et que la révision humaine n'est pas infaillible.
La source est « Best Practices for AI and Automation in Trust & Safety », Digital Trust & Safety Partnership, septembre 2024. C'est le document le plus faisant autorité dans ce domaine que quiconque peut télécharger, et il est plus à l'aise avec l'automatisation que la plupart des gens ne l'attendent.
Sur la question de savoir si l'on peut éviter l'automatisation : « L'IA et l'automatisation ne sont pas une panacée — elles s'accompagnent de plusieurs défis et limites, et l'implication humaine reste nécessaire. Cependant, traiter les abus liés au contenu et aux comportements à grande échelle n'est pas possible pour de nombreux produits et services numériques sans un certain niveau d'IA et d'automatisation. » Notez la portée de cette phrase — « pour de nombreux produits et services numériques », pas pour tout le monde. Une communauté de quatre cents personnes n'est pas dans la même situation qu'une plateforme de quatre cents millions.
Sur ce que font réellement les entreprises membres : « toutes les entreprises partenaires du DTSP interrogées pour ce rapport continuent de s'appuyer à la fois sur des outils automatisés et sur la révision et la supervision humaines pour prendre les mesures appropriées, en particulier lorsqu'une approche plus nuancée d'évaluation du contenu ou du comportement est requise. »
Et puis les deux phrases qui empêchent cet article de remplacer le battage des fournisseurs par une simplification plus propre :
- « Il est courant que les équipes de confiance et de sécurité activent une mesure d'application automatisée sans révision humaine lorsqu'un système est très confiant dans son évaluation. »
- « On suppose souvent qu'un réviseur humain sera plus précis et plus fiable qu'un système d'IA ; cependant, la révision humaine n'est pas infaillible. »
Le rapport nomme également la forme du compromis que vous faites réellement lorsque vous ajustez l'un de ces paramètres : « Optimiser le rappel (détecter davantage de violations potentielles) peut augmenter à la fois les vrais positifs et les faux positifs, ce qui peut conduire à une sur-action. À l'inverse, optimiser la précision (détection plus exacte des violations) peut réduire les faux positifs mais aussi augmenter les faux négatifs (sous-action). »
Ainsi, la conception décrite par le rapport n'est ni « laisser l'agent décider » ni « une personne approuve tout ». Elle est graduée par niveau de confiance : « Lorsque le niveau de confiance est plus faible, le système automatisé peut prendre une mesure d'application temporaire (par exemple, rétrograder temporairement le contenu ou réduire la découvrabilité du compte) et orienter le cas vers une revue humaine pour approuver ou modifier la mesure. »
C'est un modèle mental véritablement différent de celui que la plupart des propriétaires de communauté portent, et il est meilleur. Le chemin à faible confiance ne s'arrête pas pour attendre. Il prend la plus petite action réversible disponible, puis demande à une personne. La rétrogradation n'est pas un bannissement. Une claim de quête mise en attente de revue n'est pas une claim rejetée. Si vous pouvez inventer une action intermédiaire, vous n'avez plus à choisir entre rapidité et sécurité pour chaque cas.
Quelles décisions vous pouvez confier à une machine aujourd'hui
Classez les décisions selon ce qui se passe quand la machine se trompe, et non selon leur difficulté apparente. Un brouillon erroné se corrige. Un mauvais résumé se relit. Un bannissement erroné coûte à un membre son compte, et vous coûte un fil de support, une réputation et peut-être une décision. La réversibilité est l'axe qui compte.
Ce tableau est le jugement de Zealy, non une conclusion tirée de l'une des sources ci-dessus. C'est ce que nous dirions à un propriétaire de communauté qui nous poserait la question le 18 août 2026.
| Décision | Notre réponse aujourd'hui | Ce qui doit être vrai avant de l'automatiser |
|---|---|---|
| Rédiger une publication, une description de quête ou une réponse | Oui | Une personne la lit avant publication. Rien d'autre n'est requis. |
| Résumer un canal, une semaine ou une file de soumissions | Oui | La matière première reste accessible, afin qu'un lecteur puisse vérifier le résumé par rapport à elle. |
| Acheminer un signalement, une question ou une claim vers la bonne personne | Oui | Un mauvais acheminement est peu coûteux et visible, et la file n'est pas un trou noir. |
| Répondre à une question dont la réponse est documentée | Oui, avec prudence | La réponse existe par écrit dans un espace que vous contrôlez, et une réponse erronée peut être corrigée publiquement et rapidement. |
| Étiqueter, classer ou ordonner une file pour un humain | Oui | L'humain voit toujours les éléments que le modèle a classés en dernier. Ordonner n'est pas filtrer. |
| Approuver ou rejeter une soumission qui donne lieu à un paiement | Uniquement avec un parcours d'appel | Le membre est informé de la raison, une personne peut annuler le verdict, et quelqu'un surveille le taux d'annulation. |
| Retirer du contenu ou restreindre un compte | Uniquement avec une action intermédiaire réversible | Il existe un chemin à faible confiance qui fait quelque chose de plus petit que l'action complète, comme le décrit le rapport DTSP. |
| Bannir un membre purement et simplement | Non | Nous ne pouvons nommer aucun niveau de confiance qui rende cela sûr sans un humain, et l'incident Discord en est la raison. |
| Dépenser de l'argent ou déplacer des récompenses | Non | Rien dans cet article ne soutient de l'automatiser, et l'échec ne se répare pas en s'excusant. |
Le schéma de cette colonne du milieu n'est pas « les choses difficiles sont pour les humains ». Classer une file est une tâche cognitive plus difficile que bannir quelqu'un. Elle figure en haut de la liste parce qu'un mauvais classement ne coûte rien que vous ne puissiez annuler en une seconde, tandis qu'un mauvais bannissement coûte une personne.
Une remarque pratique qui ne tient pas dans un tableau. Presque toutes les communautés qui automatisent une décision oublient de mesurer le taux d'annulation par la suite, ce qui signifie que le parcours d'appel existe mais que personne ne lit ce qu'il produit. Si vous ne devez construire qu'une chose à partir de cet article, construisez le compteur. Si vous dimensionnez le volet humain de ce travail, comment déléguer les tâches communautaires couvre le coût de main-d'œuvre qui n'apparaît jamais sur une page tarifaire.
Zealy gère deux parcours d'IA, et ils répondent différemment à cette question
Via le serveur MCP de Zealy, rien de ce qu'un agent modifie ne prend effet avant qu'une personne ne l'ait validé. Dans le produit Zealy, la revue IA de Zealy tranche directement une claim de quête : elle marque la claim comme réussie ou échouée et publie sa raison au membre. Deux parcours d'IA dans une même entreprise, des réponses opposées à la même question.
Prenez le second d'abord, car c'est celui qui plaide contre nous. Sur les plans Plus et Enterprise, vous pouvez activer la revue IA pour une quête et rédiger un prompt décrivant à quoi ressemble une soumission valide. La documentation de Zealy énonce la conséquence sans l'adoucir : l'IA décide de la claim. Elle ne laisse pas de recommandation à confirmer par un humain. Elle marque la claim comme réussie ou échouée, et la raison qu'elle donne est publiée comme commentaire de revue que le membre lit dans sa boîte de réception. Ses verdicts sont attribués à un réviseur IA de Zealy qui apparaît aux côtés de votre équipe dans les analyses des meilleurs réviseurs. Si vous voulez qu'une personne prenne la décision finale, vous laissez la revue IA désactivée pour cette quête. Tout cela figure dans la documentation de Zealy sur les revues, et y est publié depuis le début.
Comparé au tableau ci-dessus, il s'agit d'une approbation ou d'un rejet automatisé sur une décision qui attribue des XP et des récompenses de rôle — et, puisque la documentation de Zealy indique qu'il incombe à la communauté de distribuer tout autre type de récompense, sur la décision qui détermine à qui la communauté doit ensuite ces récompenses. Les mesures d'atténuation sont réelles — un réviseur peut annuler tout verdict, ce qui remet la claim en attente, et le membre est informé de la raison plutôt que d'échouer silencieusement — mais la décision est prise par le modèle, et l'appel commence par le fait que le membre le remarque.
L'autre voie IA de Zealy a pris la position inverse. Via le serveur MCP de Zealy, un agent lit librement et ne peut rien modifier sans qu'une personne approuve au préalable ce changement précis. Les mécanismes de ce garde-fou, outil par outil, sont détaillés dans comment auditer l'accès d'un agent IA à votre communauté, qui énumère la surface plutôt que de la décrire.
Nous n'allons pas résoudre cette contradiction dans un article de blog, et prétendre qu'il s'agit d'une philosophie unique et cohérente serait pire que de l'imprimer. Deux équipes, deux modèles de menace, deux réponses. Ce que nous pouvons dire, c'est que cette scission n'est pas aléatoire : la voie MCP est un agent externe agissant avec l'autorité d'un administrateur sur toute une communauté, et la voie de révision est un jugement circonscrit sur une soumission face à un prompt que la communauté a elle-même écrit. Ce sont des risques différents. Savoir s'ils sont suffisamment différents pour justifier des valeurs par défaut opposées est une question légitime à nous poser, et si vous évaluez Zealy, vous devriez la poser.
Le point général dépasse notre propre produit. Quand un fournisseur vous dit que son IA garde un humain dans la boucle, demandez de quelle fonctionnalité IA il parle. Les entreprises n'ont pas une seule politique. Elles ont une politique par équipe qui a livré quelque chose.
Là où Discord et Cove font mieux que Zealy
AutoMod de Discord s'exécute au sein de Discord même et bloque un message avant que quiconque le voie ; Zealy ne se trouve pas dans le chemin des messages de Discord et ne peut rien arrêter avant sa publication. Cove propose une Moderator Console conçue sur le principe que sa propre automatisation manquera des choses. Zealy n'a pas d'équivalent.
Ce sont deux avantages différents et tous deux méritent d'être compris.
Celui de Discord est positionnel. La documentation d'Auto Moderation de Discord décrit la fonctionnalité comme une fonction « qui permet à chaque guilde de définir des règles déclenchées selon certains critères », et son BLOCK_MESSAGE action comme celle qui « bloque le message d'un membre et empêche sa publication ». Tout l'avantage tient dans cette clause : l'intervention a lieu avant la publication plutôt qu'après. Zealy se connecte à Discord, attribue des rôles et vérifie des tâches ; ce n'est pas le serveur de chat, et aucune quantité d'IA de notre côté ne change notre position. Si votre problème est « un mauvais message ne doit jamais apparaître », l'outil qui le résout est celui déjà présent dans le pipeline. Notre tour d'horizon des outils d'engagement Discord couvre ce qui a sa place dans cette couche.
Celui de Cove est architectural, et c'est le plus intéressant. Cove se décrit dans sa propre documentation comme « Cove est une plateforme no-code pour la Trust & Safety », puis écrit ceci à propos de sa propre automatisation : « Certains contenus nuisibles passeront inévitablement à travers vos règles automatisées, et ils seront signalés par vos utilisateurs. Avec notre Moderator Console, vos modérateurs peuvent examiner ces signalements et agir directement dans notre interface. »
Relisez le mot « inévitablement », dans la documentation produitd'un fournisseur, à propos du produit qu'il vous vend. Cove a conçu une surface dont toute la raison d'être est que la couche automatisée se trompera, et a intégré le flux de travail pour rattraper cela comme partie intégrante du produit plutôt que comme un ticket de support.
Zealy dispose d'une annulation sur une révision, ce qui n'est pas la même chose. L'annulation est un contrôle pour une personne qui sait déjà qu'un verdict était erroné. Ce que Cove propose, c'est un endroit où les ratés arrivent. Si vous choisissez une plateforme en partie pour sa façon de gérer ses propres échecs, c'est cette distinction qu'il faut tester, et vous devriez nous la tester aussi. Nous avons rédigé une comparaison plus large des logiciels de gestion de communauté si vous en êtes plus tôt dans cette décision, et ce qu'est Zealy si vous voulez la description simple de notre propre périmètre.
Qui répond quand l'agent se trompe
Vous. En février 2024, un tribunal canadien a ordonné à Air Canada de verser des dommages après que le chatbot de son site web a donné de fausses informations à un passager en deuil. Air Canada a soutenu, selon les mots du tribunal, que le chatbot était une entité juridique distincte responsable de ses propres actions. Le tribunal a accordé 812,02 CA$ au total, dont 650,88 CA$ de dommages.
The Register en a fait un article le 15 février 2024, signé Katyanna Quach, intitulé « Air Canada must pay damages after chatbot lies to grieving passenger about discount ». Le membre du tribunal qui a tranché l'affaire était Christopher Rivers, et The Register cite la décision caractérisant la position de la compagnie : « En substance, Air Canada suggère que le chatbot est une entité juridique distincte responsable de ses propres actions. »
Et la conclusion, cette phrase que tout propriétaire de communauté déployant un agent devrait avoir sous les yeux : « Il devrait être évident pour Air Canada qu'elle est responsable de toutes les informations figurant sur son site web. Peu importe que l'information provienne d'une page statique ou d'un chatbot. »
Une réserve sur notre façon de citer. Nous citons l'article de The Register plutôt que la décision elle-même, que nous n'avons pas lue, et nous ne donnons pas de référence jurisprudentielle.
Les montants sont faibles et le principe ne l'est pas. Un agent qui parle dans votre communauté, c'est vous qui parlez dans votre communauté. Les membres vous tiendront responsables de ce qu'il a dit, et au moins un tribunal l'a fait aussi. Cela vaut pour une politique de remboursement qu'il invente, une règle qu'il énonce et que vous n'avez jamais écrite, et un bannissement qu'il prononce. « C'est l'IA qui l'a fait » a été testé comme défense et a échoué.
Comment fixer la limite pour votre propre communauté
Notez les décisions que votre agent prendra, puis notez ce qui se passe lorsque chacune est erronée et qui la corrige. Si vous ne pouvez pas nommer la personne qui la corrige, la décision n'est pas prête à être automatisée. Cet exercice à lui seul vaut plus que n'importe quel seuil de confiance que vous choisirez à l'aveugle.
Une version courte de ce que les éléments ci-dessus étayent, dans l'ordre où nous le ferions :
- Automatisez immédiatement la mécanique. Rédaction, planification, synthèse, routage, étiquetage. Le risque est un mauvais brouillon, et vous savez déjà gérer un mauvais brouillon.
- Pour tout ce qui a une conséquence, inventez l'action intermédiaire avant d'inventer le seuil. La voie de faible confiance du rapport DTSP effectue une petite action réversible et transmet le cas. Une réclamation suspendue, une publication rétrogradée, un compte restreint mais non supprimé. Si vos deux seules options sont « agir » et « attendre », chaque seuil que vous choisirez sera erroné dans une direction.
- Traitez votre étape de revue humaine comme un logiciel, et testez-la comme un logiciel. Celui de Discord existait sur le papier et ne fonctionnait pas. Demandez quand le vôtre s'est réellement déclenché pour la dernière fois, et ce qui vous indiquerait qu'il s'est arrêté.
- Comptez les annulations. Une voie de recours que personne ne mesure n'est qu'un formulaire de réclamation. Le taux d'annulation est la seule lecture honnête que vous obtiendrez pour savoir si la décision automatisée est suffisamment bonne, et son enregistrement ne coûte presque rien.
- Partez du principe que tout ce qu'il dit vous engage. Air Canada a défendu la position inverse devant un tribunal.
La question du titre a une vraie réponse, et ce n'est pas un haussement d'épaules. Un agent IA peut aujourd'hui exécuter la mécanique de votre communauté, bien, et vous devriez le laisser faire. Il ne peut pas encore être ce qui décide qui est exclu, qui est payé, ou quelle est votre politique — non pas parce qu'il est stupide, mais parce qu'il est peu fiable d'une manière imprévisible au cas par cas, et parce que le filet de sécurité humain que vous placeriez derrière lui est un logiciel avec ses propres modes de défaillance. Concevez pour le cas où les deux se trompent, et vous aurez construit quelque chose de meilleur que ce que l'engouement ou la réaction vous auraient donné.