Dans une communauté de foi, une réponse bien écrite peut faciliter l’accès sans constituer une présence. La distinction devient technique dès qu’un formulaire ou un chatbot reçoit une demande personnelle : le système doit classifier le besoin, protéger le contenu et transférer ce qu’il ne doit pas traiter.

Je séparerais trois services. Un outil de production aide à traduire, simplifier ou sous-titrer du contenu déjà approuvé. Une FAQ retrouve les heures, lieux et ressources publiques. Un canal humain reçoit les demandes d’accompagnement. Le même modèle peut soutenir certains textes, mais les données, droits et attentes ne sont pas les mêmes.

demande -> avis clair -> tri minimal
        |-> information publique -> recherche -> réponse citée
        |-> tâche éditoriale -> brouillon -> révision humaine
        `-> besoin personnel -> file protégée -> personne responsable

Le tri ne doit pas poser de diagnostic. Il cherche des signaux simples : demande administrative, contenu public, volonté de parler à quelqu’un ou indication de danger immédiat. Une incertitude mène vers la personne, pas vers une réponse automatisée plus ambitieuse.

Un protocole pour les cas vulnérables

Je définirais avant le lancement :

1. un message visible indiquant qu’il s’agit d’un système automatisé;
2. un bouton Parler à une personne sur chaque écran;
3. une liste de situations qui coupent la génération et affichent les ressources appropriées;
4. une file protégée avec responsable, délai de réponse et relève;
5. une règle interdisant au modèle de promettre un suivi qu’il ne peut effectuer;
6. une procédure d’incident si une demande sensible est envoyée au mauvais destinataire.

Le système ne devrait pas prétendre offrir un service d’urgence. Lorsqu’un texte indique un danger immédiat, il affiche les moyens d’aide adaptés au contexte et invite à joindre une personne ou les services d’urgence. Une alerte vers un bénévole doit respecter les engagements annoncés, la disponibilité réelle et les obligations applicables; on ne cache pas une surveillance inexistante derrière une interface calme.

La confidentialité commence par la minimisation. Une question d’horaire n’a pas besoin du nom complet. Une demande personnelle ne devrait pas entrer dans les logs de débogage ni servir à l’entraînement sans base claire. Le chiffrement, les groupes d’accès, la rétention courte et un journal des consultations protègent la file. Les responsables savent quand et comment supprimer ou exporter.

Pour le contenu éditorial, on conserve source, version, modèle, brouillon et personne ayant approuvé. Une traduction est relue par quelqu’un qui comprend la langue et le contexte; une phrase spirituellement sensible ne se valide pas avec un simple correcteur grammatical. Le contenu assisté peut être identifié selon l’usage et la politique de la communauté.

Je testerais avec des questions publiques, ambiguës, personnelles et volontairement difficiles. On mesure exactitude factuelle, bon transfert, délai humain, divulgation et promesses incorrectes. Une réponse « je ne peux pas accompagner cette demande; voici comment joindre quelqu’un » peut être le meilleur résultat.

La panne laisse toujours les coordonnées humaines accessibles. Si le modèle ou la recherche tombe, le formulaire sécurisé et les numéros utiles restent. Aucun message personnel ne doit attendre dans une file invisible sans propriétaire.

L’IA peut enlever de l’administration, traduire et rendre un texte accessible. Elle ne partage pas le parcours de la personne et ne revient pas d’elle-même le lendemain. L’architecture doit rendre cette limite visible et transférer rapidement la demande dès qu’écouter la suite fait partie de la réponse.