Comment préparer le programme d'une conférence pour un assistant IA

Un schéma pratique pour préparer le programme d'une conférence destiné à un assistant IA : structure des données, base de connaissances, règles de réponse, escalade vers un humain et vérification avant le lancement.

Le programme d'une conférence destiné à un assistant IA doit fonctionner comme une base de connaissances validée, dotée d'une structure claire, de responsables de données et de règles de mise à jour. Un simple document soigné destiné à la lecture ne répond pas à ce besoin. Il faut y distinguer les faits, les recommandations et les décisions de l'organisateur. L'assistant pourra alors indiquer à un participant l'heure d'une intervention, trouver la bonne salle, expliquer la procédure d'inscription et proposer une session adaptée, sans inventer d'informations absentes.

Nous posons la principale limite avant même le chargement des données : l'assistant IA ne prend pas de décisions à la place de l'organisateur. Il ne modifie pas le planning, ne confirme pas l'accès d'un participant, ne promet pas de place disponible, n'autorise pas un intervenant en retard à monter sur scène et n'interprète pas les règles litigieuses. Ses réponses s'appuient uniquement sur la base de connaissances validée. Si une question dépasse son périmètre, si les informations se contredisent ou si la situation exige une prise de décision, la demande est transmise à un humain.

Chez Aventura, nous considérons cet assistant comme un canal supplémentaire de relation avec les participants. Il doit être relié au programme, à l'inscription, à la navigation, au fonctionnement des salles et au poste de commandement de l'événement. Un chat seul ne corrigera pas une structure de données défaillante. Si les tableaux comportent des noms de sessions différents, si un e-mail indique un ancien horaire et si les collaborateurs expliquent les règles de manière divergente, l'IA ne fera que rendre cette confusion plus visible.

Si vous préparez une conférence et souhaitez relier dès le départ le programme, le parcours des invités, les services numériques et le travail de l'équipe, demandez-nous un devis. Nous préciserons le format, le nombre de flux, la composition des participants et les missions de l'assistant.

Que faut-il préparer avant de configurer l'assistant IA ?

Préparez d'abord un programme unifié, une liste de dénominations harmonisées, une base de connaissances validée, des règles de réponse et une procédure de transfert des questions à un humain. Le modèle, l'interface et le canal de communication se choisissent ensuite. Sans cette préparation, l'automatisation ne fera qu'accélérer la propagation des contradictions entre les documents. L'équipe doit d'abord s'accorder sur la source considérée comme principale et sur la personne qui valide chaque catégorie d'informations.

L'ensemble minimal se compose de cinq éléments :

1. Un programme structuré avec des identifiants de sessions stables.
2. Des fiches pour les intervenants, les salles, les services et les règles de participation.
3. Un registre de réponses validées aux questions d'organisation.
4. Une matrice des responsabilités : ce que l'assistant communique et ce qu'il transmet à un collaborateur.
5. Un processus de mise à jour des données et de revalidation des réponses.

Il vaut mieux commencer par les besoins des participants. Une personne veut savoir où aller après l'enregistrement. Une autre hésite entre des conférences parallèles. Une troisième cherche l'intervention d'un expert précis. Une quatrième demande si l'on peut entrer dans une salle pleine. Pour les trois premières questions, des données validées suffisent généralement. La quatrième dépend déjà de la situation réelle et des prérogatives de l'équipe sur le site.

Avant la configuration, nous établissons une liste de scénarios utilisateurs. Pour chacun, nous consignons la question, les données nécessaires, la réponse autorisée et la condition de transfert à un humain. Cette liste aide à ne pas charger l'assistant de tout et n'importe quoi. Il n'aura peut-être pas besoin du budget interne, des échanges avec les intervenants ou du scénario technique. En revanche, il a impérativement besoin des noms actuels des salles, des horaires des sessions, des règles d'accès et des contacts du service d'assistance.

La conception de l'assistant fait partie de la préparation globale d'une conférence, d'un forum ou d'un séminaire. Elle ne se limite pas au programme. Les réponses aux participants dépendent de l'enregistrement, du plan du site, de la disponibilité des salles, du transport, de la restauration, de la diffusion et des décisions du PC de crise.

Lors de la première réunion de travail, nous posons à l'organisateur les questions suivantes :

1. Qui utilisera l'assistant : les participants inscrits, les invités non inscrits, les intervenants, les partenaires ou les collaborateurs ?
2. Où sera-t-il accessible : sur le site, dans l'application, dans l'espace personnel ou dans une messagerie ?
3. Quelles questions doit-il traiter sans l'intervention d'un collaborateur ?
4. Quelles informations peuvent changer le jour de l'événement ?
5. Qui valide chaque catégorie de données ?
6. À qui la question est-elle transmise lorsqu'il n'y a pas de réponse exacte ?
7. Dans quel délai l'équipe doit-elle voir la demande transmise ?
8. Quelles données ne doivent pas être montrées à certaines catégories d'utilisateurs ?

D'après les réponses, nous déterminons ce que l'assistant pourra faire et où un humain sera nécessaire. Sans ces limites, il commencera à répondre à des questions pour lesquelles il n'existe ni données fiables ni autorisation.

La frontière des responsabilités : l'IA informe, l'humain décide

L'assistant IA peut trouver, recouper et expliquer des informations confirmées. La décision reste celle de l'organisateur ou du responsable désigné. Nous inscrivons d'emblée cette frontière dans les règles du système et ne laissons pas le choix à l'appréciation du modèle. Nous listons séparément les actions qui exigent une vérification de l'inscription, de l'état de la salle, de la sécurité ou d'un autre fait issu du système de travail.

Nous répartissons les actions en trois niveaux.

Les deux premiers niveaux peuvent être automatisés dans les limites de la base de connaissances. Le troisième niveau n'est pas confié à l'assistant s'il n'existe pas, derrière lui, un processus confirmé spécifique et un système externe qui exécute l'action. Même en cas d'intégration technique, la décision doit être prise selon les règles de l'organisateur, et non selon une libre interprétation du texte.

Par exemple, l'assistant peut indiquer qu'une inscription préalable est prévue pour la session. Il peut afficher le lien correspondant si ce lien est à jour et accessible à ce participant. Mais il ne doit pas écrire que la personne « entrera à coup sûr dans la salle » s'il n'a pas de confirmation de réservation ni de données sur l'admission en cours.

La même règle s'applique à la modification du programme. L'assistant peut recevoir le message : « L'intervenant est en retard ». Il ne doit pas déplacer les interventions de sa propre initiative. Il transmet l'information au coordinateur et, après une décision approuvée, reçoit la nouvelle version du planning.

Nous formulons la règle de base sans détour :

L'assistant ne répond que sur la base de connaissances confirmée. Il ne prend pas de décisions à la place de l'organisateur. Si les données sont insuffisantes, si les sources divergent ou si la question exige une exception aux règles, l'assistant transmet la demande à un humain.

Il est utile de reproduire cette règle dans le cahier des charges, les instructions système, les scénarios de test et le mémo destiné aux collaborateurs. Ainsi, l'équipe n'attend pas de l'outil des prérogatives qu'il n'a pas.

Quelles données sont nécessaires pour chaque session ?

Chaque session doit disposer d'une fiche structurée distincte. Elle contient l'identifiant, le nom, l'horaire, le lieu, les participants, le format, le public, le statut et le propriétaire des données. Un paragraphe dans un PDF ne donne pas à l'assistant une base fiable pour rechercher et comparer. La fiche permet de mettre à jour un seul champ et de vérifier quels canaux doivent recevoir la nouvelle version.

Un identifiant stable est particulièrement important. Le titre d'une intervention peut changer, mais son code interne reste le même. Nous utilisons un identifiant stable unique dans toutes les intégrations. Ainsi, le programme, l'inscription, la navigation et les notifications relient les enregistrements d'une même session.

La fiche de session peut inclure les champs suivants :

Le champ « public cible » ne doit pas se transformer en argumentaire publicitaire. Mieux vaut écrire : « responsables de services commerciaux, directeurs de succursales, responsables du développement du réseau de partenaires » plutôt que « pour tous ceux qui veulent en savoir plus ». L'assistant pourra associer un rôle précis au programme, mais il ne doit pas deviner les intérêts à partir de mots vides.

Le format de participation est également décrit explicitement. Si un atelier exige un ordinateur portable et qu'une table ronde n'accepte les questions que via l'application, ces conditions figurent dans la fiche. Si l'accès est réservé à un groupe déterminé, l'assistant indique la règle et propose le canal de vérification prévu. Il ne fait pas d'exception lui-même.

Pour un programme hybride, nous enregistrons en outre le lien de diffusion, l'heure d'ouverture de la salle, les règles d'accès, la disponibilité d'un enregistrement et le canal d'assistance technique. La préparation de ce parcours est liée à la logique générale de l'événement hybride : le participant en ligne doit disposer d'un parcours complet, et non d'un simple lien sans contexte.

Si le programme, l'inscription et les services numériques vivent encore dans des fichiers séparés, l'organisation d'un événement d'entreprise aide à les réunir dans un seul circuit de travail. Nous relions les propriétaires des données, les délais de mise à jour et la vérification des réponses avant l'arrivée des participants.

Un lexique unique pour le programme

Tous les systèmes et tous les collaborateurs doivent utiliser les mêmes noms de sessions, de salles, de rôles et de services. L'assistant IA a besoin d'un lexique qui relie le nom officiel aux variantes de requête acceptables, sans créer de nouveaux objets. Le lexique signale également les anciens noms, les abréviations ambiguës et les mots que les participants emploient souvent à l'oral.

Un participant peut écrire « salle principale », « plénière », « grande scène » ou l'ancien nom d'un espace. Le lexique aide à comprendre la requête. Dans sa réponse, l'assistant utilise toutefois le nom public actuel : par exemple, « Salle plénière ».

Nous ajoutons au lexique :

1. Les noms officiels des salles et les variantes courantes.
2. Les noms complets des intervenants et les abréviations acceptables.
3. Les noms des entreprises et des produits dans leur graphie validée.
4. Les synonymes de formats : conférence, intervention, session, table ronde.
5. Les noms internes et publics des services.
6. Les termes qu'il ne faut pas confondre.
7. Les anciens noms, avec l'indication de leur remplacement actuel.

Le lexique ne doit pas modifier le sens à l'insu de tous. « Inscription à la conférence » et « inscription à une session distincte » sont deux actions différentes. « Diffusion » et « enregistrement d'une intervention » ne signifient pas non plus toujours la même chose. Si on les réunit comme de parfaits synonymes, l'assistant se mettra à donner des instructions erronées.

Nous signalons à part les correspondances sensibles. Lors d'une conférence à plusieurs parcours, deux sessions peuvent porter des noms similaires. Des intervenants peuvent avoir le même nom de famille. Dans différents bâtiments du site, on trouve des numéros de salle identiques. Dans ce cas, l'assistant doit poser une question de clarification plutôt que de choisir la première option trouvée.

Nous harmonisons les noms en huit étapes :

1. Nous rassemblons tous les noms issus du programme, du site, des e-mails, de l'application et du plan du site.
2. Nous choisissons une seule variante publique pour chaque entité.
3. Nous attribuons un identifiant stable.
4. Nous ajoutons les variantes orales acceptables.
5. Nous signalons les anciens noms.
6. Nous vérifions les correspondances et les abréviations ambiguës.
7. Nous transmettons le lexique aux responsables du programme, de l'inscription et de la navigation.
8. Nous interdisons la création de nouveaux noms publics sans mise à jour du lexique.

À première vue, il s'agit d'une tâche éditoriale. En pratique, le travail de l'équipe et l'orientation des participants en dépendent. Si le site indique « Salle A », l'application « Nord » et la signalétique « Salle de conférence n° 1 », le participant n'est pas tenu de deviner qu'il s'agit du même espace.

Nous publions des analyses concrètes de programmes, de parcours invités et de documents de travail dans la chaîne Telegram d'Aventura.

Comment constituer une base de connaissances validée ?

La base de connaissances ne doit contenir que des informations dotées d'un propriétaire clair, d'un statut et d'une date de mise à jour. Le simple chargement d'un dossier de documents sans sélection ne rend pas les réponses fiables : on peut y trouver en même temps un brouillon, une version approuvée et un e-mail obsolète. Avant de connecter l'assistant, l'équipe analyse les sources, supprime les doublons et définit une priorité pour chaque type de fait.

Nous séparons la source de données du texte de réponse convivial. La source peut être une ligne du programme, une règle d'inscription ou une fiche de lieu. La réponse destinée au participant est formulée plus simplement, mais n'ajoute aucune promesse nouvelle.

Pour chaque entrée, il est utile de conserver :

• un identifiant unique ;
• la question ou le thème ;
• la réponse validée ;
• la source au sein du projet ;
• le propriétaire de l'information ;
• le statut ;
• la date et l'heure de la dernière mise à jour ;
• le public autorisé à recevoir la réponse ;
• la durée de validité ;
• la condition de transfert de la question à un collaborateur.

Les statuts doivent être sans ambiguïté. Nous appliquons la logique suivante : « brouillon », « en cours de vérification », « validé », « remplacé », « retiré ». L'assistant ne reçoit que les entrées validées. Un document « en cours de vérification » peut être accessible au rédacteur, mais ne doit pas influencer la réponse publique.

Une attention particulière est requise pour les questions qui semblent simples mais dépendent de la situation actuelle :

• reste-t-il des places dans la salle ;
• peut-on s'inscrire sur place ;
• un participant sera-t-il admis après le début ;
• peut-on remplacer le représentant d'une entreprise ;
• l'enregistrement d'une session fermée est-il disponible ;
• peut-on obtenir la présentation d'un intervenant ;
• le transfert a-t-il changé ;
• l'entrée sans document est-elle autorisée ;
• peut-on photographier un support précis.

Pour celles-ci, une réponse permanente ne suffit pas. Il faut soit des données à jour issues du système responsable, soit un transfert à un humain. Si l'assistant n'a pas accès au taux de remplissage réel de la salle, il ne doit pas présenter une prévision comme un fait.

Il est pratique de diviser la base de connaissances en plusieurs couches.

Si la conférence se déroule en ligne, nous relions la base de connaissances au parcours réel de l'événement en ligne et de la diffusion. Un lien sans règles d'accès, heure d'ouverture et contact de support répond rarement à la question du participant.

Les données personnelles et l'accessibilité sont définies avant le lancement

Seules les informations nécessaires aux scénarios annoncés sont transmises à l'assistant. La fiche publique d'un intervenant, le statut d'inscription d'un participant et un contact interne ont des modes d'accès différents. Nous définissons à l'avance la finalité du traitement, la composition des champs, la durée de conservation, le périmètre des collaborateurs et la procédure de suppression. Le client convient du schéma précis avec son juriste et son responsable de la protection des données personnelles, en tenant compte de la Federal Law No. 152-FZ, de l'infrastructure utilisée et d'un éventuel transfert vers un service d'IA externe.

Les numéros de téléphone personnels, les adresses internes, les données de voyage et les besoins spécifiques ne figurent pas dans l'index général de l'assistant. Si le statut d'un participant précis est nécessaire pour répondre, le système doit vérifier les droits d'accès et n'afficher que le résultat nécessaire. L'historique des dialogues est lui aussi conservé selon des règles approuvées, et non indéfiniment « au cas où ».

L'interface doit être accessible au clavier et aux lecteurs d'écran. Les erreurs et les changements opérationnels sont signalés par du texte, et non uniquement par la couleur ou une animation. Le statut « salle modifiée » doit comporter un libellé clair et un message identifiable par programme, afin qu'un lecteur d'écran puisse le vocaliser. Ces exigences sont conformes à WCAG 2.2, mais ne remplacent pas la vérification de l'accessibilité physique du site.

Format de réponse et interdictions pour l'assistant

L'assistant donne d'abord une réponse courte et confirmée, puis précise les conditions et propose l'étape suivante. S'il n'a pas de données exactes, il signale clairement la limite et transmet la question à un collaborateur. Cet ordre aide le participant à comprendre rapidement le fait, à en voir les limites et à ne pas prendre une hypothèse du modèle pour une décision de l'organisateur.

Nous définissons la structure de la réponse :

1. Réponse directe à la question.
2. Détails confirmés.
3. Condition ou limite, le cas échéant.
4. Étape suivante pour le participant.
5. Transfert à un humain lorsque la décision exige une autorisation.

Exemple de réponse correcte :

La session « Gestion d'une équipe distribuée » commencera à 15h10 dans la salle « Neva ». Une inscription préalable est nécessaire pour y assister. Vous pouvez vérifier votre statut dans votre espace personnel. Si l'inscription ne s'affiche pas, je transmettrai la question à un collaborateur de l'inscription.

Une mauvaise réponse paraît assurée, mais ajoute une promesse non confirmée :

Présentez-vous à la salle, on vous laissera forcément entrer.

Dans la seconde formulation, l'assistant a pris la décision à la place de l'équipe d'accès. Même s'il reste habituellement des places libres, cela ne confirme pas la situation précise.

Dans les instructions, nous interdisons à l'assistant :

• d'inventer un horaire, un lieu, un nom ou une règle absents ;
• de choisir entre des versions contradictoires sans priorité définie ;
• de promettre un accès, une place, un cadeau, un repas ou l'accès à une inscription ;
• de modifier le programme ;
• de confirmer une inscription sans les données du système responsable ;
• de divulguer des contacts confidentiels et des documents internes ;
• de donner une évaluation juridique, médicale ou technique à la place d'un spécialiste compétent ;
• de présenter une hypothèse comme une décision de l'organisateur ;
• de poursuivre une réponse assurée après avoir détecté une contradiction ;
• de communiquer des données annulées ou révoquées.

Une phrase unique pour la limite des connaissances est également utile :

Je n'ai pas de réponse confirmée dans la base de connaissances actuelle. Je transmettrai la question à un collaborateur de l'équipe.

Elle vaut mieux qu'une tentative de combler le silence par une hypothèse. Pour le participant, l'important est un parcours correct, non l'apparence de l'omniscience.

Comment structurer le processus de mise à jour du programme ?

Chaque modification suit un seul parcours : demande, décision du propriétaire, mise à jour de la source, publication d'une nouvelle version, synchronisation de la base de connaissances et vérification de la réponse. Un message dans le chat ne constitue pas une mise à jour du programme. Jusqu'à validation, l'assistant continue d'utiliser la version en vigueur ou indique honnêtement que les informations sont en cours de vérification.

Nous structurons le processus ainsi :

1. Le demandeur décrit la modification proposée et sa raison.
2. Le propriétaire du programme évalue l'impact sur les participants, les intervenants, les salles et la production.
3. L'organisateur habilité prend la décision.
4. Le rédacteur met à jour la version principale du programme.
5. Le système attribue à la nouvelle version un numéro et une heure de publication.
6. Le responsable met à jour les enregistrements associés de la base de connaissances.
7. L'équipe vérifie le site, l'application, la navigation et les notifications.
8. Pour une modification critique, un message est adressé aux participants.
9. L'assistant passe des questions de contrôle sur la session modifiée.
10. La version précédente passe au statut « remplacée », mais reste conservée dans le journal.

Une modification doit avoir une date d'entrée en vigueur. Si le report est encore en discussion, l'assistant continue d'utiliser le planning en vigueur. Si la décision est validée mais que la nouvelle version n'a pas atteint le canal des participants, le poste de commandement doit voir cet écart et le combler.

Pour chaque correction, nous évaluons les dépendances :

• la salle change-t-elle ;
• un conflit avec la session suivante apparaît-il ;
• une notification aux participants inscrits est-elle nécessaire ;
• faut-il mettre à jour le lien de diffusion ;
• la navigation change-t-elle ;
• les interprètes et l'équipe technique sont-ils concernés ;
• faut-il mettre à jour les sous-titres, les fonds d'écran et les écrans ;
• l'inscription du participant est-elle conservée ;
• à qui transmettre les questions sur le report.

Si seule la formulation de la description change, les participants n'ont généralement pas besoin d'un message urgent. Si la session déménage dans un autre bâtiment, une simple correction dans la base de connaissances ne suffit pas. Il faudra une notification, une navigation et des collaborateurs sur l'ancien parcours.

Une modification opérationnelle reçoit une durée de validité. Le message « le début est retardé » ne peut pas rester dans les réponses après la fin de la session. Pour les statuts temporaires, nous fixons l'heure de publication, l'échéance de révision prévue et le propriétaire de la prochaine mise à jour.

Versions, priorités et source unique de vérité

Le programme doit avoir une version principale unique, et chaque canal doit disposer d'un ordre de synchronisation clair avec celle-ci. L'assistant IA ne doit pas reconstituer le planning à partir d'une présentation, d'un e-mail, d'un tableur et d'une publication dans le chat en même temps. Pour chaque information, l'équipe désigne une source prioritaire, un responsable et une date de dernière confirmation.

Nous désignons une source principale distincte pour chaque catégorie :

La source principale n'est pas nécessairement un seul fichier pour tout le projet. Le programme est responsable du planning, mais n'est pas tenu de stocker le statut réel des inscriptions. L'essentiel est que chaque information ait un seul responsable et une seule source prioritaire.

La version du programme doit être compréhensible par un humain. Nous enregistrons le numéro, la date, l'heure, l'auteur de la publication et une brève liste des modifications. Si l'assistant utilise un export, celui-ci conserve les mêmes marqueurs. En cas d'erreur, il est alors possible d'établir quel jeu de données était disponible au moment de la réponse.

Il ne faut pas mettre à jour uniquement le texte de la réponse. Si une session est déplacée, on modifie d'abord la source du programme, puis l'enregistrement associé. Sinon, l'assistant répondra correctement, mais le site continuera d'afficher l'ancien horaire.

Pour la partie technique de la conférence, nous appliquons la même approche. Les présentations, les vidéos et les signaux doivent avoir des versions validées. Le matériel nécessaire est sélectionné après le programme et les exigences de contenu ; les tâches spécifiques au son sont liées au projet d'équipement sonore, et non résolues par la formule générale « il y aura un micro ».

Quelles questions faut-il transmettre à un humain ?

On transmet à un humain les questions sans réponse confirmée, les demandes d'exception, les contradictions dans les données, les réclamations et les actions nécessitant l'autorité de l'organisateur. Transmettre une question à un collaborateur est une fonction normale de l'assistant. Elle est nécessaire lorsque la réponse dépend de la situation réelle, contient des informations sensibles ou exige une décision absente de la base de connaissances.

Nous établissons à l'avance une carte d'escalade.

La transmission doit contenir le contexte. Le collaborateur a besoin de la question d'origine, des données déjà vérifiées, de l'identifiant de session, du canal de réponse et de l'heure de la demande. Si l'assistant ne transmet que la phrase « aidez le participant », l'humain recommence la conversation depuis le début.

Le processus d'escalade se déroule ainsi :

1. L'assistant détermine que la question dépasse ses attributions.
2. Il indique au participant pourquoi un collaborateur est nécessaire.
3. Il collecte uniquement les données nécessaires au routage.
4. Il crée une demande avec le contexte.
5. Il choisit la catégorie de la question et le collaborateur responsable.
6. Il montre au participant la confirmation de la transmission.
7. Le collaborateur prend la décision dans le système de travail.
8. La décision est renvoyée au participant par le canal convenu.
9. Si la réponse peut être réutilisée, le propriétaire l'examine pour la base de connaissances.
10. La nouvelle entrée n'est publiée qu'après vérification.

Le dernier point est important. Une décision isolée ne devient pas toujours une règle générale. Si l'organisateur a autorisé un intervenant à passer par l'entrée de service, l'assistant ne doit pas conseiller cet itinéraire à tous les participants.

Nous définissons également une limite d'urgence. En cas de message sur une menace pour la sécurité, une dégradation de l'état de santé, un enfant perdu, un conflit ou une autre situation urgente, l'assistant ne tente pas de mener une consultation. Il affiche le contact approuvé et transmet immédiatement le signal au collaborateur responsable selon le scénario du site.

Vérification avant l'ouverture de l'accès aux participants

Avant le lancement de l'assistant, nous vérifions l'exactitude des réponses et son comportement face à l'incertitude, à la modification du programme et aux tentatives d'obtenir des informations confidentielles. Un bon résultat signifie que le système respecte les limites fixées, utilise une version à jour et transmet la question litigieuse à l'employé compétent. Le nombre total de réponses automatiques reste une métrique secondaire.

Nous effectuons la vérification en plusieurs passes.

1. Vérification des faits. Nous comparons les noms, les horaires, les salles, les intervenants et les liens avec les sources principales.
2. Vérification des variantes de langage. Nous posons une même question de façon brève, familière, avec des fautes de frappe et avec l'ancien nom de la salle.
3. Vérification de l'ambiguïté. Nous utilisons des noms de famille identiques, des sessions similaires et des formulations incomplètes.
4. Vérification des données manquantes. Nous posons des questions sur ce qui n'est pas dans la base de connaissances.
5. Vérification des habilitations. Nous demandons de garantir une place, de modifier une inscription ou d'accorder une exception.
6. Vérification des conflits. Nous créons volontairement deux versions différentes d'un même fait dans l'environnement de test.
7. Vérification de la mise à jour. Nous déplaçons une session et observons quand la nouvelle version apparaît dans toutes les réponses.
8. Vérification des données confidentielles. Nous demandons un numéro de téléphone interne, un document interne ou un lien inaccessible.
9. Vérification de l'escalade. Nous évaluons le destinataire, l'exhaustivité du contexte et la réception de la demande par l'employé.
10. Vérification de la restauration. Nous ramenons le système à la version opérationnelle et répétons les questions de contrôle.

Il est pratique de regrouper les questions de contrôle par rôle. Un responsable RH peut s'intéresser au parcours sur la marque employeur. Un marketeur cherche des études de cas clients. Un spécialiste technique pose des questions sur la démonstration du produit. Un intervenant vérifie l'heure d'arrivée. Un participant avec un accès en ligne cherche la diffusion. Chaque rôle a ses propres questions, mais les réponses proviennent toujours de la base commune validée.

Les développeurs ne sont pas les seuls à participer aux tests. Le propriétaire du programme vérifie le planning, le service d'inscription - les statuts de participation, le responsable du site - la navigation, le producteur en ligne - la diffusion, et le rédacteur - la clarté des formulations. Le chef de projet valide la matrice des habilitations.

Le jour de la conférence, nous fixons des points de contrôle :

1. Avant l'ouverture des inscriptions, nous vérifions le programme initial et les contacts du support.
2. Avant le premier bloc, nous vérifions les changements opérationnels.
3. Avant les parcours parallèles, nous vérifions les salles et les restrictions d'accès.
4. Après un déplacement important, nous posons une série de questions de contrôle.
5. Après la fin du programme, nous désactivons les statuts temporaires et mettons à jour les liens vers les supports.
6. Après l'événement, nous passons l'assistant en mode où il ne répond qu'aux questions confirmées sur les enregistrements, les supports et les retours.

Nous tenons le journal des erreurs par catégories. Nous signalons séparément une source erronée, une version obsolète, une formulation peu claire, une erreur dans le choix du responsable et un dépassement des habilitations. Cela aide à corriger le processus, et pas seulement une réponse isolée.

Sources

• Schema.org: Event - champs de l'événement, sessions enfants, dates, lieu, participants et statut.
• Google Cloud: Grounding with Agent Search - ancrage de la réponse dans les données de l'entreprise et métadonnées des extraits justificatifs.
• OWASP GenAI: Misinformation - risque d'inventions plausibles, recherche sur des données vérifiées, vérification automatique et contrôle humain.
• W3C: Web Content Accessibility Guidelines 2.2 - messages d'erreur textuels, libellés des éléments et messages de statut accessibles.
• Federal Law No. 152-FZ « On Personal Data » - finalités, composition, exactitude, durées et protection des données personnelles dans un projet russe.
• IETF: RFC 5545 - iCalendar - UID permanent, fuseau horaire, horodatages de modification et séquence des versions d'une entrée de calendrier.
• Microsoft Learn: Hand off to a live agent - transfert de la conversation et du contexte pertinent à un collaborateur.