IA proactive

La spec décrit l'IA comme assistant de recherche et de chat. Mais Claude peut faire bien plus : maintenir la qualité de la base, détecter les anomalies, enrichir automatiquement, alerter sur les risques. Cette page liste les usages "proactifs" à implémenter.

Le principe

L'IA réactive : "L'utilisateur demande quelque chose, l'IA répond." L'IA proactive : "L'IA détecte un problème ou une opportunité, et alerte l'utilisateur ou propose une action."

Pour Reciprok, l'IA proactive devient un agent de maintenance qui tourne en arrière-plan et garde la base saine.

Use case 1, Curation automatique de la KB

Le problème

Les KnowledgeEntry accumulent au fil du temps. Risques :

• Doublons : un membre redécrit deux fois la même salle dans deux audios différents
• Conflits : la fiche dit "80 places assises", mais le dernier audio dit "100"
• Obsolescence : un audio de 2024 dit "ouvert tous les jours", mais en 2026 le membre a fermé le lundi

Solution : worker hebdomadaire de curation

export async function curateMemberKnowledgeBase(memberId: string) {
  const entries = await db.query.knowledgeEntry.findMany({
    where: eq(knowledgeEntry.memberId, memberId),
  });

  if (entries.length < 5) return; // Pas assez pour curer

  // 1. Détection de doublons sémantiques (via cosine sur les embeddings)
  const duplicates = findSemanticDuplicates(entries, threshold: 0.92);

  // 2. Détection de conflits (Claude analyse)
  const conflicts = await claude.messages.create({
    model: "claude-sonnet-4-5",
    messages: [{
      role: "user",
      content: `Voici les ${entries.length} entrées KB du membre #${memberCode}.
                Détecte les conflits ou contradictions, et propose des résolutions.
                Format JSON.`,
    }],
  });

  // 3. Notification équipe avec actions suggérées
  await createNotification({
    type: "kb_curation_needed",
    title: `KB de #${memberCode} à curer`,
    body: `${duplicates.length} doublons, ${conflicts.length} conflits détectés`,
    actions: ["Réviser maintenant", "Auto-fix", "Ignorer"],
  });
}

Trigger : worker quotidien qui curate les membres modifiés récemment.

Use case 2, Hygiène de la base membres

Le problème

70 000 membres → forcément des fiches incomplètes, obsolètes, ou abandonnées.

Solution : audit automatique

Worker quotidien qui scanne et flag :

Dashboard "Hygiène base" qui agrège tout ça avec un score de qualité par membre :

#102 Restaurant du Lac    Score: 92/100 ✅
#157 Le Loft              Score: 45/100 ⚠️  (manque photos, KB vide)
#298 Domaine de la Plaine Score: 78/100 (description courte)

Use case 3, Enrichissement automatique

Important : pas de scraping de sites tiers dans la roadmap V1. Les enrichissements via LinkedIn, Société.com, scraping de sites web ou Google Places sont pensés pour la V2 minimum, après stabilisation du cœur fonctionnel et validation juridique (RGPD, CGU des sources, robustesse). Ce qui suit décrit la vision cible, pas le périmètre court terme.

À partir d'un email entrant (V2+)

Quand une nouvelle demande arrive par email :

1. L'IA extrait l'organisateur (nom, email, entreprise), déjà fait en V1
2. Enrichissement auto (V2+) :
   • Annuaire SIRENE (API publique gratuite) → SIRET, taille, secteur pour les entreprises FR
   • LinkedIn via une API officielle (si on en obtient une) → poste, entreprise
   • Domaine email → site web → ABOUT page → résumé activité (si on a un consentement / accord)
3. Le profil organisateur est pré-rempli avec ces données
4. L'utilisateur valide ou corrige

À partir d'une fiche membre (V2+)

Quand on crée un nouveau membre :

1. L'IA récupère le site web du membre (avec son accord explicite, le membre est dans notre réseau)
2. Parse la page "événements" / "privatisation"
3. Extrait les capacités, tarifs, ambiance
4. Pré-remplit la fiche
5. L'utilisateur et le membre valident

Différence clé avec le scraping anonyme : ici le membre est partie prenante du réseau, il a signé pour qu'on traite ses données. Pas de problématique RGPD ni CGU.

À partir d'avis Google (V3+)

Pour les membres qui ont une fiche Google Maps, et uniquement via l'API officielle Google Places (jamais de scraping) :

1. Récupère les avis publics via Google Places API
2. L'IA analyse les tendances : ambiance perçue, type de clientèle, points forts récurrents, points faibles
3. Crée des KnowledgeEntry typées audit_note avec source google_reviews

Soumis à : budget API Google + accord du membre référencé.

Use case 4, Alertes intelligentes

Sur les demandes

L'IA scanne chaque nouvelle demande et alerte si :

• Budget anormalement bas pour la zone : "Budget 30% sous la moyenne pour le 8ème, voici 3 alternatives plus accessibles"
• Date conflictuelle : "5 demandes ce jour-là, attention à la disponibilité"
• Organisateur à risque : "Cet organisateur a annulé 3 demandes sur les 12 derniers mois"
• Manque évident : "Pas de format spécifié et pas de nombre de personnes, recommande d'envoyer une requalif"

Sur les membres

• Surcharge : "#102 a déjà 4 événements ce mois-ci, attention à ne pas surcharger"
• Mauvais retour récent : "Le dernier événement chez #157 a eu un retour client négatif (note 2/5)"
• Refus en série : "#205 a refusé 3 demandes en 2 semaines, vérifier qu'il est toujours actif"
• Excellent track record : "#298 a 100% de gagnés sur les 5 derniers mois pour ce type d'événement"

Sur le pipeline

• Stagnation : "Cette demande n'a pas avancé depuis 5 jours, relance recommandée"
• Catalogue ignoré : "L'organisateur n'a pas ouvert le catalogue depuis 3 jours, envoyer une relance ?"
• Réponse manquante : "Le membre #102 n'a pas confirmé sa dispo demandée il y a 4 jours"

Use case 5, Génération de contenu

Brouillons d'emails personnalisés

Au lieu de templates statiques, l'IA génère un email adapté au contexte :

• Pour la requalification : ton et formulation adaptés au profil de l'organisateur (entreprise vs particulier, ton formel vs décontracté)
• Pour le catalogue : intro personnalisée qui fait écho aux besoins exprimés
• Pour les non-retenus : message de courtoisie qui mentionne le contexte et reste professionnel

Récap hebdomadaire automatique

Tous les lundis, l'IA génère un récap pour l'équipe :

Semaine du 6 au 12 mai 2026

Demandes traitées : 18
- 5 nouvelles
- 8 en cours de négociation
- 3 gagnées (commission totale : 2 450€)
- 2 perdues

Top membres de la semaine :
- #102 : 3 catalogues, 1 gagné
- #205 : 2 catalogues, 1 gagné

Points d'attention :
- 4 demandes sans action depuis 48h
- 2 catalogues envoyés sans relance après 5 jours
- 1 commission à facturer (#298, 350€)

Suggestions d'optimisation :
- L'organisateur "Tech Corp" a 3 demandes annulées, à creuser
- Les rooftops du 8ème ont un taux de conversion 25% supérieur au reste

Use case 6, Comparaison concurrentielle

L'IA peut analyser l'historique pour identifier des patterns :

• Pourquoi #102 perd contre #205 : "Sur les 12 derniers mois, dans le 8ème, #205 a gagné 12 demandes vs #102 qui en a gagné 8. L'analyse des catalogues montre que #205 a un budget moyen plus bas et propose des menus végétariens, ce qui matche les demandes récentes"
• Tendances saisonnières : "Les rooftops convertissent 2x plus en mai-juin qu'en hiver, prévoir plus de catalogues rooftop ce mois-ci"

Architecture des workers

Implémentation : un process Bun séparé qui :

1. Consomme une queue Postgres LISTEN/NOTIFY pour les triggers
2. Fait tourner des cron jobs avec node-cron ou un simple setInterval
3. Appelle Claude/OpenAI pour les analyses
4. Crée des Notification pour l'équipe quand quelque chose mérite attention

Garde-fous

L'IA proactive peut vite devenir bruyante ou coûteuse. À surveiller :

1. Cap de notifications par jour : max 20 alertes proactives par utilisateur (au-delà, on agrège)
2. Throttling des analyses : ne pas curer la même KB 2x dans la semaine
3. Coût plafonné : les workers IA ont un budget mensuel séparé du chat (ex: 100€/mois max)
4. Opt-out par catégorie : l'utilisateur peut désactiver certains types d'alertes
5. Apprentissage des "ignorés" : si l'utilisateur ignore systématiquement un type d'alerte, le worker s'adapte

Roadmap

Principe : on n'introduit une fonctionnalité IA proactive que si on a déjà au moins 3 mois de données réelles sur lesquelles la valider. Pas d'IA proactive aveugle.