Catalogue de cas d'usage

Ce catalogue sert à deux choses :

1. Identifier rapidement si un besoin client correspond à un pattern connu.
2. Accélérer le cadrage en partant d'une architecture de flow documentée et ajustable.

Chaque cas d'usage décrit le problème, la structure de flow type, les nodes utilisés, et les points d'attention.

1. Routage de requêtes par règles (sans IA)

Le besoin

Un service client veut router automatiquement les demandes entrantes vers le bon département selon des critères simples (mot-clé, catégorie, priorité), sans utiliser de LLM.

Structure de flow

Trigger Channel → Condition (catégorie ?)
  → "technique" → HTTP Request (créer ticket IT)
  → "commercial" → HTTP Request (notifier équipe vente)
  → "urgent" → HTTP Request (escalade manager)
  → else → Réponse ("Merci, un agent vous recontactera")

Nodes utilisés

Complexité

Faible. Pas de prompt engineering, pas de coût LLM. Idéal pour commencer avec nAIxus.

Points d'attention

• Définir les règles de routage avec les équipes métier.
• Prévoir un fallback "autre" pour les cas non couverts.
• Le routage par règles est fiable et déterministe — à préférer quand les catégories sont bien définies.

2. Pipeline de données (transformation + envoi)

Le besoin

Un système envoie des données brutes (webhook, fichier, formulaire) qui doivent être transformées et transmises à un autre système, sans intervention IA.

Structure de flow

Trigger Channel (SDK) → Code (transformer les données) 
  → HTTP Request (envoyer au SI cible) 
  → Condition (succès ?) → Réponse

Nodes utilisés

Complexité

Faible. Traitement déterministe, pas de coût LLM. Convient aux intégrations simples.

Points d'attention

• Valider la structure des données entrantes dans le node Code.
• Gérer les erreurs HTTP (timeout, 500) avec une branche de fallback.
• Utile quand le client a besoin d'une passerelle entre systèmes avec de la logique métier.

3. Chatbot de support client

Le besoin

Un client veut offrir un assistant conversationnel à ses utilisateurs finaux pour répondre aux questions fréquentes, orienter vers le bon service, et escalader quand l'IA ne sait pas répondre.

Structure de flow

Trigger Channel → Agent (FAQ) → Condition (confiance ?) 
  → oui → Réponse directe
  → non → Human Input (escalade) → Réponse manuelle

Nodes utilisés

Complexité

Moyenne. Le prompt de l'agent est le cœur du travail. L'escalade HITL nécessite un processus humain derrière.

Points d'attention

• Définir clairement les critères d'escalade (ne pas tout escalader).
• Le prompt doit inclure les limites de l'assistant ("ne pas inventer de réponses").
• Prévoir un message d'attente si l'opérateur humain n'est pas immédiatement disponible.

4. Q&A sur base documentaire (RAG)

Le besoin

Un client veut permettre à ses collaborateurs de poser des questions sur un corpus de documents internes (procédures, réglementations, manuels techniques) et obtenir des réponses sourcées.

Structure de flow

Trigger Channel → Parse Document (indexation) → Agent (RAG)
  → Réponse avec sources

Nodes utilisés

Complexité

Élevée. Le RAG nécessite une pipeline d'indexation en amont, et la qualité dépend fortement du découpage et de l'embedding des documents.

Points d'attention

• La qualité des réponses dépend directement de la qualité des documents sources.
• Prévoir un mécanisme de mise à jour quand les documents changent.
• Les réponses doivent citer leurs sources pour validation humaine.
• Attention aux hallucinations : le prompt doit explicitement interdire d'inventer.

5. Qualification de prospects (lead scoring)

Le besoin

Une équipe commerciale veut automatiser le premier contact avec des leads entrants : poser des questions de qualification, scorer le prospect, et router vers le bon commercial.

Structure de flow

Trigger Channel → Agent (qualification) → Set Variable (score) 
  → Condition (score > seuil ?)
    → oui → HTTP Request (CRM : créer opportunité)
    → non → Agent (réponse générique)

Nodes utilisés

Complexité

Moyenne. Le prompt de qualification est l'élément clé. L'intégration CRM ajoute de la complexité technique.

Points d'attention

• Le prospect ne doit pas avoir l'impression de remplir un formulaire. L'agent doit être conversationnel.
• Définir les critères de scoring avec l'équipe commerciale avant de commencer.
• L'envoi au CRM via HTTP Request nécessite de connaître l'API du CRM client.

6. Extraction de données depuis des documents

Le besoin

Un client reçoit de gros volumes de documents (factures, contrats, rapports) et veut en extraire automatiquement des informations structurées.

Structure de flow

Trigger Manual → Parse Document → Agent (extraction) 
  → Code (formater JSON) → HTTP Request (envoyer au SI)

Nodes utilisés

Complexité

Élevée. La qualité dépend de la variabilité des formats de documents. Les documents scannés (OCR) ajoutent une couche de difficulté.

Points d'attention

• Tester avec un échantillon représentatif des documents réels (pas des exemples propres).
• Prévoir une validation humaine (HITL) pour les documents ambigus.
• Le prompt d'extraction doit être très structuré : lister exactement les champs attendus.
• Prévoir le cas où un champ est absent du document.

7. FAQ interne d'entreprise

Le besoin

Les RH, le juridique ou l'IT veulent offrir un assistant interne qui réponde aux questions récurrentes des collaborateurs (congés, procédures, politique de sécurité…).

Structure de flow

Trigger Channel (Teams/Slack) → Agent (FAQ interne)
  → Condition (réponse trouvée ?)
    → oui → Réponse
    → non → "Contactez le service X"

Nodes utilisés

Complexité

Faible à moyenne. C'est le cas d'usage le plus simple si la base de connaissances est bien structurée.

Points d'attention

• Le prompt doit délimiter le périmètre ("tu ne réponds qu'aux questions RH").
• Mettre à jour les documents sources régulièrement (sinon réponses obsolètes).
• Déployer d'abord sur un canal interne (Slack) avant d'élargir.

8. Assistant de rédaction de contenu

Le besoin

Une équipe marketing ou communication veut un outil qui aide à rédiger des emails, des publications, des fiches produit, en respectant le ton et la charte de l'entreprise.

Structure de flow

Trigger Channel → Agent (rédaction) → Human Input (validation)
  → Agent (révision si feedback) → Réponse finale

Nodes utilisés

Complexité

Faible. Le prompt est le cœur : ton, longueur, structure, exemples. Le flow en lui-même est simple.

Points d'attention

• Fournir des exemples de productions attendues dans le prompt (few-shot).
• Le loop "rédaction → feedback → révision" peut nécessiter plusieurs itérations.
• Attention à la propriété intellectuelle : le contenu généré doit être vérifié.

9. Routage intelligent de requêtes

Le besoin

Un service desk ou un centre de contact reçoit des demandes variées et veut les router automatiquement vers le bon service (technique, commercial, RH, juridique…).

Structure de flow

Trigger Channel → Agent (classification) → Condition (catégorie ?)
  → "technique" → HTTP Request (créer ticket IT)
  → "commercial" → HTTP Request (notifier équipe vente)
  → "autre" → Human Input (triage manuel)

Nodes utilisés

Complexité

Moyenne. La précision de la classification dépend de la qualité du prompt et de la clarté des catégories.

Points d'attention

• Définir les catégories avec les équipes métier. Moins de 10 catégories pour commencer.
• Tester avec des requêtes réelles pour calibrer le prompt.
• Prévoir un fallback "autre" pour les cas ambigus.

Matrice de synthèse

Utiliser ce catalogue en cadrage

1. Identifiez le pattern — Quel cas d'usage se rapproche le plus du besoin exprimé ?
2. Évaluez les écarts — Quelles différences entre le pattern et le besoin réel ?
3. Vérifiez les capacités — Consultez la matrice de capacités pour les limitations.
4. Estimez la charge — La complexité indiquée donne un ordre de grandeur. Le vrai effort est dans le prompt engineering et l'intégration SI.