# D4 · Workflow Integration and Solution Design

Appliquer Claude à de vrais processus métier, concevoir des flux avec supervision humaine, intégrer les outils existants, décider construire-ou-escalader, communiquer la valeur et les limites, et mesurer l’impact du pilote à la mise à l’échelle.

import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components';

À **16 %**, c’est l’un des domaines les plus lourds — environ **10 items sur 60**. Il dépasse les prompts isolés pour aller vers la *conception de solutions* : examiner un processus métier entier, trouver où Claude ajoute de la valeur, garder un humain dans la boucle là où cela compte, intégrer les outils que les gens utilisent déjà, et savoir quand un besoin a dépassé une interface de chat et doit être escaladé aux Developers ou Architects. Il évalue aussi votre façon de communiquer la valeur et les limites aux parties prenantes, et de mesurer et mettre à l’échelle l’impact de manière responsable.

## Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Appliquer Claude à l’**analyse de besoins, la recherche, la planification et l’optimisation de processus**.
2. **Cartographier un processus métier** vers les étapes où Claude ajoute de la valeur.
3. Concevoir des points de contrôle avec **supervision humaine (human-in-the-loop)** proportionnés au risque.
4. **Intégrer** Claude aux outils existants (e-mail, docs, tableurs, Slack, CRM) via des connectors.
5. Décider **construire-ou-escalader** : reconnaître quand un besoin exige une solution API/agent et le router vers les Developers/Architects.
6. **Communiquer la valeur et les limites** aux parties prenantes honnêtement.
7. **Mesurer l’impact** — temps gagné, qualité, adoption — et passer du **pilote à la mise à l’échelle**.

---

## 4.1 Where Claude adds value in a process

Toutes les étapes d’un processus ne conviennent pas. Claude ajoute le plus de valeur sur les étapes **fortes en langage, à jugement faible à modéré, répétitives et réversibles**.

| Caractéristique de l’étape | Adéquation à Claude | Exemple |
| --- | --- | --- |
| Lire/résumer beaucoup de texte | Élevée | Digérer une pile de réponses à un appel d’offres |
| Rédiger des premières versions | Élevée | Brouillons d’e-mails, briefs, fiches de poste |
| Structurer/reformater l’information | Élevée | Transformer des notes en tableau structuré |
| Brainstorming / génération d’options | Élevée | Idées de campagne, listes de risques |
| Classification/extraction routinière | Élevée (Haiku) | Étiqueter des tickets, extraire des champs de facture |
| Décision finale à conséquence juridique/financière/RH | Faible — l’humain décide | Approuver un contrat, embaucher |
| Actions irréversibles ou réglementées | Faible — point de contrôle humain | Envoyer à un régulateur, émettre un paiement |

:::tip[Signal d’examen]
Les bonnes réponses placent Claude sur les étapes de **rédaction, synthèse et analyse** et gardent les humains sur les étapes de **décision et d’action irréversible**. Méfiez-vous des options qui confient une décision réglementée finale au modèle — elles sont fausses.
:::

## 4.2 Mapping a business process

Avant d’automatiser quoi que ce soit, cartographiez le processus de bout en bout, puis placez Claude délibérément.

<Steps>

1. **Listez les étapes** du processus actuel, avec leurs entrées, sorties et responsables.

2. **Marquez chaque étape** comme : automatiser-avec-revue, assister-l’humain, ou garder-entièrement-humaine.

3. **Identifiez les entrées dont Claude a besoin** à chaque étape assistée (documents, données, contexte) et où elles vivent (e-mail, Drive, CRM).

4. **Insérez des points de contrôle de revue** après toute étape dont la sortie alimente une décision ou une action externe/irréversible.

5. **Estimez la valeur** (temps gagné, qualité, cohérence) et le risque, pour prioriser les étapes à traiter en premier.

</Steps>

```text
Exemple : processus mensuel de revue fournisseurs
Étape 1  Collecter les rapports fournisseurs (e-mail/Drive) → un connector les apporte
Étape 2  Résumer chaque rapport                        → Claude rédige  [revue]
Étape 3  Comparer aux KPI                               → Claude analyse [revue]
Étape 4  Rédiger la note de revue                       → Claude rédige  [revue]
Étape 5  Décider des renouvellements                   → l’HUMAIN décide
Étape 6  Envoyer les décisions aux fournisseurs        → l’HUMAIN envoie
```

## 4.3 Human-in-the-loop design

La supervision humaine (human-in-the-loop, HITL) signifie qu’une personne relit ou approuve avant qu’une sortie ne soit utilisée. La **profondeur** de la revue évolue avec le risque.

| Niveau de risque | Conception HITL |
| --- | --- |
| Faible (brouillon interne, brainstorming) | L’auteur relit rapidement avant usage |
| Moyen (e-mail client, rapport interne avec chiffres) | Vérifier faits/chiffres ; un second relecteur pour le ton |
| Élevé (publication externe, contrat, conseil réglementé) | Revue SME + validation documentée avant diffusion |
| Irréversible (envoyer, payer, publier, supprimer) | Point de contrôle d’approbation humaine explicite — jamais automatisé pour un flux d’utilisateur métier |

La formulation de l’examen : les bonnes réponses gardent un **point de contrôle d’approbation humaine** pour les actions irréversibles ou réglementées et ne s’appuient jamais sur la confiance du modèle pour le sauter.

:::caution[La confiance n’est pas un point de contrôle]
« Claude était confiant, on a donc sauté la revue » est toujours faux pour des actions à enjeux élevés/irréversibles. Le point de contrôle existe parce que la *conséquence* est grave, quel que soit l’assurance de la sortie.
:::

## 4.4 Integrating with existing tools

La valeur métier vient souvent d’amener Claude aux données que les gens ont déjà, via des **connectors**.

| Outil | Valeur du connector | Points de vigilance |
| --- | --- | --- |
| **E-mail (Gmail/Outlook)** | Résumer des fils, rédiger des réponses | L’accès à une boîte entière est large ; délimitez-le |
| **Docs / Drive** | Ancrer les réponses dans de vrais documents | Donne accès à tout ce que le compte peut voir |
| **Tableurs** | Lire les données, structurer les sorties | À associer à l’analysis tool pour des maths fiables |
| **Slack** | Résumer des canaux, rédiger des messages | L’historique d’un canal peut contenir des données sensibles |
| **CRM** | Extraire le contexte de comptes, rédiger la prise de contact | PII clients — à traiter selon la politique de données (D6) |
| **Calendar** | Contexte d’agenda, préparation de réunion | Révèle participants et sujets |

Deux principes pour l’examen :

1. **Moindre privilège** — ne connectez que ce dont la tâche a besoin ; les connectors exposent tout ce que le compte connecté peut atteindre.
2. **La sensibilité des données voyage avec les données** — connecter un CRM fait entrer les PII clients dans le périmètre ; les règles de gouvernance de D6 s’appliquent.

:::tip[Signal d’examen]
Quand un énoncé mentionne de connecter Gmail/Drive/Slack/CRM, attendez-vous à une considération de *permission/périmètre* dans la bonne réponse, pas seulement un gain de productivité.
:::

## 4.5 Build-vs-escalate

La compétence déterminante de l’Associate est de connaître le plafond d’une solution fondée sur le chat. Au-delà se trouve le territoire du Developer/Architect.

| Signal dans le besoin | Solution | Qui en est responsable |
| --- | --- | --- |
| Ponctuel, avec supervision humaine, utilise l’UI de chat | Flux d’utilisateur métier (Projects, connectors) | **Vous** |
| Récurrent mais toujours piloté par l’humain, besoin d’une config partagée | Project / Skills | **Vous** |
| Doit s’exécuter automatiquement, de système à système, sans humain par exécution | Intégration API / agent | **Developers** |
| Agent autonome multi-étapes, orchestration d’outils, logique d’escalade | Architecture agentique | **Architects** |
| Fort volume, programmatique, besoin de SLA, gestion d’erreurs, tentatives | Application conçue | **Developers/Architects** |

```text
Zone utilisateur métier ────────────► Frontière d’escalade ──────────────►
chat, Projects, connectors,          intégrations API, agents autonomes,
Skills, artifacts, research          pipelines batch, outils personnalisés, SLA
(humain dans la boucle à chaque exéc.) (s’exécute sans humain à chaque fois)
     VOUS en êtes responsable              les DEVELOPERS / ARCHITECTS le sont
```

:::caution[Le piège de l’escalade]
Si un scénario a besoin que quelque chose s’exécute **automatiquement sans humain à chaque fois**, ou nécessite une **intégration programmatique, une gestion d’erreurs ou un agent autonome**, la bonne réponse est d’escalader — pas de le bricoler dans l’UI de chat. Tenter de construire une automatisation de production en tant qu’utilisateur métier est une mauvaise réponse classique.
:::

## 4.6 Communicating value and limitations

Les parties prenantes ont besoin d’un tableau honnête : ce que Claude fait bien, ce qu’il ne fait pas et ce qui reste humain.

| À communiquer | À éviter de communiquer |
| --- | --- |
| Valeur concrète (« réduit le temps de premier jet d’environ 60 % ») | Battage vague (« l’IA transformera tout ») |
| Que la sortie est vérifiée avant usage | Qu’elle est « toujours exacte » |
| Que les humains sont responsables des décisions et des sorties | Que l’outil « prend la décision » |
| La gestion des données et la conformité à la politique | Le silence sur données/vie privée |
| Où il NE sera PAS utilisé (limites) | Promettre une applicabilité universelle |

Présenter Claude comme un **collaborateur de rédaction/analyse compétent dont l’équipe vérifie et assume la sortie** est à la fois exact et ce que l’examen récompense.

## 4.7 Measuring impact

Vous ne pouvez justifier une mise à l’échelle sans mesure. Utilisez un petit ensemble honnête de métriques.

| Dimension | Exemple de métrique | Piège à éviter |
| --- | --- | --- |
| **Temps gagné** | Heures/semaine récupérées ; réduction du temps de cycle | Compter le temps gagné mais ignorer la reprise due aux erreurs |
| **Qualité** | Taux d’erreur/défaut, retouches du relecteur, cohérence | Seulement une « satisfaction » agrégée ; vérifiez la qualité par type de tâche |
| **Adoption** | % de l’équipe qui l’utilise, fréquence, usage durable | Inscriptions de vanité sans usage durable |
| **Coût** | Coût du modèle/plan vs valeur livrée | Ignorer le coût du surdimensionnement des modèles |

:::note[Les métriques agrégées peuvent cacher un échec]
« La qualité globale est en hausse » peut masquer un type de tâche que Claude gère mal. Mesurez par segment / par type de tâche, pas seulement une moyenne — la même leçon que le principe d’évaluation par segment de l’examen Architect.
:::

## 4.8 Pilot to scale

<Steps>

1. **Pilotez** sur un processus bien délimité, réversible et à forte valeur, avec un petit groupe.

2. **Mesurez** le temps gagné, la qualité et l’adoption par rapport à une référence ; recueillez les retours des utilisateurs.

3. **Standardisez** ce qui fonctionne dans des Projects/Skills et des instructions partagées pour que les résultats soient reproductibles.

4. **Ajoutez de la gouvernance** — règles de gestion des données, points de contrôle de revue, responsabilité — avant un déploiement large (D5/D6).

5. **Mettez à l’échelle** vers plus d’équipes, en surveillant les mêmes métriques ; escaladez tout ce qui a dépassé l’UI de chat vers les Developers/Architects.

</Steps>

Ne mettez pas à l’échelle un pilote non mesuré, et ne mettez pas à l’échelle un flux dont les points de contrôle de revue ou la gestion des données n’ont pas été définis.

---

## 4.9 A build-vs-escalate decision tree

Le jugement le plus testé de D4 est *de savoir si un besoin est encore une solution d’utilisateur métier ou a franchi le territoire du Developer/Architect*. Routez chaque scénario par ces questions.

```text
Doit-il s’exécuter SANS humain impliqué à chaque exécution ?
│
├─ Oui ─► De système à système / autonome. ESCALADEZ vers les Developers/Architects.
│         (intégration API, pipeline batch, agent autonome)
│
└─ Non ─► Un humain est dans la boucle à chaque fois. Restez en zone utilisateur métier.
          │
          Le MÊME contexte/procédure revient-il sur de nombreux chats ?
          │
          ├─ Oui ─► Configurez un Project (contexte) et/ou une Skill (procédure).
          │
          └─ Non ─► Ponctuel : un chat, un artifact ou une tâche de research bien spécifiés.

Déclencheurs d’escalade supplémentaires (l’un suffit ⇒ escalader) :
• Intégration programmatique avec l’API d’un autre système
• Besoin de SLA, tentatives, gestion d’erreurs, supervision
• Orchestration d’outils multi-étapes autonome / logique de décision
• Débit fort volume, non supervisé
```

| Besoin | Responsable | Mécanisme |
| --- | --- | --- |
| Tâche ponctuelle avec supervision humaine | **Vous** | Chat / artifact / research |
| Récurrente pilotée par l’humain, config partagée | **Vous** | Project + Skills |
| S’exécute automatiquement, sans humain par exécution | **Developers** | Intégration API / agent |
| Orchestration autonome, décisions d’outils | **Architects** | Architecture agentique |

:::caution[Le piège de l’escalade]
« Il suffit de construire l’automatisation nocturne dans le chat » est faux dès que le processus doit s’exécuter *sans humain à chaque fois*. La compétence de l’Associate est de reconnaître le plafond et d’escalader — pas de bricoler une automatisation de production dans l’UI de chat.
:::

## 4.10 Change management and adoption

Un flux techniquement solide échoue tout de même si les gens ne l’adoptent pas ou ne lui font pas confiance. Le rôle de l’Associate inclut le volet humain du déploiement.

| Levier | Ce qu’il fait | Piège à éviter |
| --- | --- | --- |
| **Formation & habilitation** | Enseigne les habitudes de vérification, pas seulement les prompts | Supposer que le personnel apprendra seul l’usage responsable |
| **Responsabilité claire** | Nomme qui maintient le Project/la Skill et qui valide | Configs orphelines qui pourrissent (lien avec D5) |
| **Boucle de retour** | Les utilisateurs signalent les échecs ; la config s’améliore | Traiter le pilote comme « terminé » au lancement |
| **Calibrage de la confiance** | Fixe les attentes : assistant, pas oracle ; vérifier | Surpromettre l’exactitude (perte de confiance à la première erreur) |
| **Déploiement par phases** | Pilote → mesurer → standardiser → gouverner → mettre à l’échelle | Déploiement big-bang sans référence |

**Avant/après — une mise à jour aux parties prenantes :**

```text
Avant (battage) :  « Notre nouvelle IA fait les rapports maintenant — c’est quasi automatique. »
Problème :         Surpromet autonomie et exactitude ; prépare une perte de confiance et
                   invite à sauter le point de contrôle de revue.
Après (honnête) :  « Claude rédige les rapports et a réduit le temps de premier jet d’environ 50 %.
                   Un responsable nommé vérifie les chiffres et valide avant diffusion,
                   et nous ne l’utilisons pas pour du conseil réglementé. Voici comment signaler
                   un mauvais brouillon. »
Effet :            Des attentes justes, un point de contrôle de revue respecté, et un
                   canal de retour — le cadrage que l’examen récompense.
```

:::tip[Signal d’examen]
Les bonnes options de communication aux parties prenantes associent une *valeur concrète* à des *limites honnêtes et une déclaration de vérification/responsabilité*. Les options qui promettent l’autonomie, la perfection ou « l’outil décide » sont fausses.
:::

## 4.11 Common misconceptions

| Idée reçue | Réalité | Pourquoi cela compte à l’examen |
| --- | --- | --- |
| « Si Claude est confiant, on peut sauter le point de contrôle de revue. » | La confiance n’est pas un contrôle ; le point de contrôle existe à cause de la conséquence. | Distracteur de dépendance à l’auto-déclaration. |
| « Automatiser tout le processus pour maximiser les économies. » | Les étapes irréversibles/réglementées ont besoin d’un point de contrôle d’approbation humaine. | Distracteur de sur-automatisation. |
| « Un utilisateur métier peut construire l’intégration non supervisée. » | L’automatisation de système à système s’escalade aux Developers. | Item de frontière d’escalade. |
| « Connecter toute la boîte mail/le CRM par commodité. » | Moindre privilège : ne connectez que ce dont la tâche a besoin. | Distracteur de sur-privilège. |
| « Le temps gagné prouve que le pilote a réussi. » | Il faut aussi mesurer la qualité (par type de tâche) et la reprise. | Distracteur de métrique agrégée/temps seul. |
| « Dire à la direction que c’est toujours exact pour obtenir l’adhésion. » | Surpromettre perd la confiance à la première erreur. | Item de communication honnête. |
| « Mettre à l’échelle d’abord, ajouter la gouvernance ensuite. » | Règles de données, points de contrôle et responsabilité viennent *avant* le déploiement large. | Item de mise à l’échelle responsable. |
| « Claude devrait prendre la décision réglementée finale. » | Les humains décident ; Claude rédige/synthétise. | Item de responsabilité de décision. |

## 4.12 Scenario walkthrough – from pilot to scale in customer support

**Scénario.** Une équipe de support pilote Claude pour rédiger des réponses aux tickets entrants. Après un mois, le temps de traitement moyen est en baisse de 40 % et le CSAT s’est maintenu. Le responsable du support veut (a) le déployer à toutes les 12 équipes la semaine prochaine et (b) « laisser Claude auto-envoyer les confirmations de remboursement simples pour aller plus vite », le justifiant par « Claude est confiant sur celles-là ». Les tickets arrivent via une boîte partagée que l’équipe veut connecter en bloc, et certains tickets contiennent des PII clients.

**Trace de raisonnement d’expert.**

1. **Séparer les deux demandes.** Le déploiement large et l’auto-envoi des remboursements sont des décisions différentes à risques différents ; traitez-les séparément.
2. **L’auto-envoi des remboursements est irréversible et financier.** Il exige un point de contrôle d’approbation humaine. « Claude est confiant » est une dépendance à l’auto-déclaration — jamais un point de contrôle valide. Rejetez l’auto-envoi.
3. **Le connector de boîte doit être à moindre privilège.** Connecter toute la boîte surexpose les données ; délimitez à ce dont la tâche a besoin. Les PII dans les tickets déclenchent la politique de gestion des données (D6).
4. **Mesurer les bonnes choses avant de mettre à l’échelle.** Un gain de temps de 40 % et un CSAT stable sont encourageants mais agrégés ; vérifiez la qualité *par type de ticket* (p. ex. les brouillons de remboursement et de réclamation sont-ils aussi bons que les brouillons de FAQ ?) et les taux de retouche des relecteurs. Ne mettez pas à l’échelle sur une seule métrique de temps.
5. **Ajouter la gouvernance avant le déploiement large.** Définissez les règles de gestion des données, le point de contrôle de revue et une responsabilité nommée ; standardisez la configuration fonctionnelle dans un Project/une Skill pour que les 12 équipes se comportent de façon cohérente.
6. **Phaser le déploiement.** Étendez par étapes avec les mêmes métriques et un canal de retour, plutôt qu’un big-bang la même semaine.
7. **Communiquer honnêtement.** Présentez la valeur avec ses limites et le point de contrôle de revue, pour que les équipes ne sautent pas la vérification.

**Décision correcte à l’examen :** garder un point de contrôle d’approbation humaine sur les envois de remboursement (rejeter l’auto-envoi fondé sur la confiance), délimiter le connector au moindre privilège avec les PII traitées selon la politique, vérifier la qualité par segment, ajouter règles de données/points de contrôle/responsabilité et standardiser dans des Projects/Skills, puis phaser le déploiement avec une mesure continue. **Pas** l’auto-envoi sur la confiance, **pas** la connexion de toute la boîte, **pas** la mise à l’échelle la même semaine sur une seule métrique de temps.

---

## Pièges de l’examen dans ce domaine
| Piège | Pourquoi c’est faux |
| --- | --- |
| « Laisser Claude prendre la décision finale d’embauche/de contrat » | Les décisions réglementées à enjeux élevés restent humaines ; Claude assiste, ne décide pas |
| « Automatiser tout le processus de bout en bout, sans humain » | Les étapes irréversibles/réglementées ont besoin d’un point de contrôle d’approbation humaine |
| « Connecter tout le CRM/la boîte mail pour une petite tâche » | Viole le moindre privilège ; les connectors exposent tout ce que le compte peut atteindre |
| « Construire soi-même le pipeline e-mail-vers-base dans le chat » | L’automatisation de système à système s’escalade aux Developers |
| « Dire aux parties prenantes que la sortie est toujours exacte » | Surpromesse ; communiquez les limites et la vérification |
| « Mettre à l’échelle après un pilote sans métriques » | Vous ne pouvez ni justifier ni gouverner une montée en charge jamais mesurée |
| « Ne rapporter que la satisfaction globale » | Les métriques agrégées cachent les échecs par type de tâche |
| « Sauter la revue parce que le modèle était confiant » | La confiance ne remplace pas un point de contrôle de revue fondé sur le risque |
| « Mettre à l’échelle d’abord et ajouter la gouvernance après » | Règles de données, points de contrôle de revue et responsabilité viennent avant le déploiement large |
| « Déploiement big-bang à toutes les équipes d’un coup » | Phasez-le : pilote, mesure contre une référence, standardisation, gouvernance, puis mise à l’échelle |
| « Supposer que le personnel apprendra seul l’usage responsable » | L’adoption a besoin de formation, de responsabilité et d’une boucle de retour, pas seulement d’un outil |
| « Un chat ponctuel convient à un processus récurrent piloté par l’humain » | Un contexte/une procédure partagés récurrents appartiennent à un Project et/ou une Skill |

---

## Questions d’entraînement
Chaque item indique combien de réponses sélectionner. Tentez avant de révéler.

<Accordions>
  <AccordionItem title="Q1 · Une équipe cartographie un processus de reporting mensuel. Quelle étape est le MEILLEUR candidat à garder ENTIÈREMENT humaine ? (Sélectionnez une réponse)">
    A. Résumer les rapports sources.
    B. Rédiger le récit du rapport.
    C. Décider des réaffectations de budget d’après le rapport.
    D. Reformater des notes en tableau.

    **Réponse : C.** Une décision de réaffectation de budget porte une conséquence financière et devrait rester une décision humaine ; Claude assiste la rédaction et la synthèse autour. Résumer (A), rédiger (B) et reformater (D) sont exactement les étapes fortes en langage et réversibles que Claude accélère avec revue.
  </AccordionItem>

  <AccordionItem title="Q2 · Un manager veut automatiser l’envoi d’e-mails de remboursement client de bout en bout sans humain, déclenché par le jugement de Claude. Quelle est la MEILLEURE conception ? (Sélectionnez une réponse)">
    A. L’automatiser entièrement ; Claude a généralement raison.
    B. Garder un point de contrôle d’approbation humaine avant l’envoi de tout e-mail de remboursement, puisque envoyer et rembourser sont irréversibles.
    C. L’automatiser mais demander à Claude de noter sa propre confiance et n’envoyer que lorsqu’il est confiant.
    D. Utiliser le modèle le plus cher pour qu’aucun point de contrôle ne soit nécessaire.

    **Réponse : B.** Envoyer et rembourser sont irréversibles et financiers — ils exigent un point de contrôle d’approbation humaine. L’automatisation complète (A) supprime le point de contrôle ; la confiance auto-évaluée (C) n’est pas un point de contrôle valide (dépendance à l’auto-déclaration) ; le niveau de modèle (D) ne supprime pas le risque.
  </AccordionItem>

  <AccordionItem title="Q3 · Une tâche a besoin que Claude rédige des réponses aux e-mails de support. Quelles DEUX considérations s’appliquent lors de la connexion du compte de messagerie ? (Sélectionnez deux réponses)">
    A. Ne connecter que ce dont la tâche a besoin, en suivant le moindre privilège.
    B. Reconnaître que le connector expose les données auxquelles le compte peut accéder, ce qui peut inclure des informations sensibles.
    C. Connecter toute la boîte mail de l’entreprise par commodité.
    D. Supposer que les connectors n’ont aucune implication de gouvernance des données.
    E. Utiliser un modèle plus gros pour rendre le connector plus sûr.

    **Réponse : A et B.** Les connectors doivent être délimités à la tâche, et ils mettent en jeu tout ce que le compte peut atteindre, donc la sensibilité des données et la gouvernance s’appliquent. Tout connecter (C) viole le moindre privilège ; les connectors ont clairement des implications de gouvernance (D) ; la taille du modèle (E) est sans rapport avec le périmètre d’accès.
  </AccordionItem>

  <AccordionItem title="Q4 · Un utilisateur métier a besoin d’un processus où les factures entrantes sont lues, des champs extraits, et un système financier mis à jour automatiquement chaque nuit sans humain par exécution. Quelle est la réponse CORRECTE ? (Sélectionnez une réponse)">
    A. Le construire dans claude.ai chat avec un Project.
    B. Reconnaître qu’il s’agit d’une intégration API/agent et escalader vers les Developers/Architects.
    C. Le faire manuellement dans le chat chaque nuit.
    D. Utiliser research mode.

    **Réponse : B.** Un traitement automatique, de système à système et non supervisé est une solution de développeur/architecte ; l’Associate l’escalade. Un Project (A) n’exécute pas d’automatisation ; le faire manuellement (C) va à l’encontre de l’objectif ; research mode (D) est sans rapport.
  </AccordionItem>

  <AccordionItem title="Q5 · Un Associate présente le pilote à la direction. Quelle affirmation est la PLUS appropriée ? (Sélectionnez une réponse)">
    A. « Claude est toujours exact, on peut donc supprimer la revue humaine. »
    B. « Claude a réduit le temps de premier jet d’environ la moitié ; les humains vérifient toujours les chiffres et sont responsables des décisions finales, et nous ne l’utilisons pas pour du conseil réglementé. »
    C. « L’IA transformera chaque processus de l’entreprise. »
    D. « L’outil prend désormais les décisions. »

    **Réponse : B.** Elle donne une valeur concrète, énonce la vérification et la responsabilité humaine, et nomme une limite — honnête et exact. Les autres surpromettent l’exactitude (A), font du battage vague (C) ou faussent la responsabilité (D).
  </AccordionItem>

  <AccordionItem title="Q6 · Un pilote a réduit le temps de traitement moyen mais un responsable demande si la qualité s’est maintenue. Quelle approche de métrique est la MEILLEURE ? (Sélectionnez une réponse)">
    A. Ne rapporter que le score de satisfaction global.
    B. Mesurer la qualité par type de tâche (p. ex. les retouches nécessaires du relecteur et le taux d’erreur par catégorie), pas seulement une moyenne.
    C. Supposer que la qualité est bonne parce que le temps a baissé.
    D. Compter les inscriptions.

    **Réponse : B.** Des métriques de qualité par segment révèlent les types de tâches où Claude sous-performe, qu’une moyenne cacherait. La satisfaction globale (A) et supposer la qualité (C) masquent les échecs ; les inscriptions (D) mesurent l’adoption, pas la qualité.
  </AccordionItem>

  <AccordionItem title="Q7 · Quelle étape est le MEILLEUR premier candidat pour un pilote Claude ? (Sélectionnez une réponse)">
    A. Approuver des demandes de prêt.
    B. Rédiger des comptes rendus de réunion internes à partir de notes.
    C. Envoyer des dépôts réglementaires automatiquement.
    D. Émettre des paiements clients.

    **Réponse : B.** Une tâche réversible, interne, forte en langage et à faible risque est le pilote à faibles enjeux idéal. Les autres sont réglementées, irréversibles ou financières et sont de mauvais premiers pilotes.
  </AccordionItem>

  <AccordionItem title="Q8 · Un flux rédige des clauses de contrat pour l’équipe juridique. Quelle conception HITL est appropriée ? (Sélectionnez une réponse)">
    A. Aucune revue ; publier les clauses directement aux contreparties.
    B. Revue SME (juridique) et validation documentée avant qu’une clause ne soit utilisée en externe.
    C. Demander à Claude de confirmer qu’il est confiant, puis utiliser les clauses.
    D. Automatiser parce que les contrats sont routiniers.

    **Réponse : B.** Un contenu juridique utilisé en externe est à enjeux élevés et réglementé : il faut une revue SME et une validation documentée. Publier directement (A) et automatiser (D) sautent le point de contrôle ; l’auto-confiance (C) n’est pas un point de contrôle valide.
  </AccordionItem>

  <AccordionItem title="Q9 · Une équipe veut mettre à l’échelle un pilote réussi à toute l’organisation. Que doit-il y avoir en place AVANT la mise à l’échelle ? (Sélectionnez deux réponses)">
    A. Un impact mesuré par rapport à une référence.
    B. Des règles de gestion des données, des points de contrôle de revue et une responsabilité définis.
    C. Le modèle le plus cher pour tout le monde.
    D. La suppression de toute revue humaine pour aller plus vite.
    E. Une interdiction des connectors.

    **Réponse : A et B.** Une mise à l’échelle responsable exige la preuve de l’impact et l’échafaudage de gouvernance (règles de données, points de contrôle de revue, responsabilité). Standardiser sur le modèle le plus cher (C) gaspille du coût ; supprimer la revue (D) est dangereux ; interdire les connectors (E) n’est pas un prérequis de mise à l’échelle.
  </AccordionItem>

  <AccordionItem title="Q10 · Claude est appliqué à l’analyse de besoins pour un nouvel outil interne. Où ajoute-t-il le PLUS de valeur ? (Sélectionnez une réponse)">
    A. Prendre la décision finale d’investissement go/no-go.
    B. Synthétiser les entretiens de parties prenantes et les documents en un brouillon structuré de besoins que les humains affinent et approuvent.
    C. Valider le budget.
    D. Engager l’entreprise auprès d’un fournisseur.

    **Réponse : B.** Synthétiser des entrées en un brouillon structuré est une assistance à forte valeur ; les humains affinent et approuvent. Les décisions d’investissement (A), la validation de budget (C) et les engagements auprès de fournisseurs (D) sont des décisions humaines à conséquence.
  </AccordionItem>

  <AccordionItem title="Q11 · Un connector CRM est proposé pour que Claude rédige une prise de contact personnalisée. Quelle est la considération CLÉ de gouvernance ? (Sélectionnez une réponse)">
    A. Aucune ; la rédaction est inoffensive.
    B. Le CRM contient des PII clients, donc la politique de gestion des données et la délimitation au moindre privilège s’appliquent.
    C. Seul le choix du modèle importe.
    D. La prise de contact doit toujours être entièrement automatisée.

    **Réponse : B.** Un connector CRM fait entrer les PII clients dans le périmètre, déclenchant la politique de gestion des données et la délimitation au moindre privilège (D6). Ce n’est pas inoffensif (A) ; le choix du modèle (C) est secondaire ; l’automatisation (D) n’est pas requise et augmenterait le risque.
  </AccordionItem>

  <AccordionItem title="Q12 · Une partie prenante demande à l’Associate de garantir que Claude ne fera jamais d’erreur dans le nouveau flux. Quelle est la MEILLEURE réponse ? (Sélectionnez une réponse)">
    A. Le garantir pour sécuriser l’adhésion.
    B. Expliquer que des erreurs sont possibles, ce qui est la raison pour laquelle la vérification et les points de contrôle de revue humaine sont intégrés au flux, et décrire ces garde-fous.
    C. Dire que les erreurs n’arrivent jamais avec le modèle supérieur.
    D. Refuser de déployer quoi que ce soit.

    **Réponse : B.** Une communication honnête reconnaît la faillibilité et pointe les garde-fous qui la gèrent. Garantir la perfection (A, C) est faux et prépare l’échec ; refuser d’emblée (D) écarte une valeur réelle que les garde-fous rendent sûre.
  </AccordionItem>

  <AccordionItem title="Q13 · Un processus récurrent piloté par l’humain a besoin des mêmes instructions et docs de référence à chaque fois, mais d’aucune automatisation. Quelle est la BONNE solution et le bon responsable ? (Sélectionnez une réponse)">
    A. Escalader vers les Developers pour une construction API.
    B. L’Associate configure un Project (instructions personnalisées + knowledge), éventuellement avec des Skills pour les étapes reproductibles.
    C. Construire un agent autonome.
    D. Continuer à coller le contexte manuellement pour toujours.

    **Réponse : B.** Un travail récurrent, piloté par l’humain avec un contexte partagé est en plein dans la zone utilisateur métier : un Project (et des Skills) dont l’Associate est responsable. Il n’a besoin ni d’escalade développeur (A) ni d’un agent autonome (C) ; le collage manuel (D) est inefficace et incohérent.
  </AccordionItem>

  <AccordionItem title="Q14 · Un responsable de support veut que Claude auto-envoie les confirmations de remboursement simples « parce qu’il est confiant sur celles-là » et connecte toute la boîte partagée par commodité. Quelles DEUX corrections sont les PLUS appropriées ? (Sélectionnez deux réponses)">
    A. Garder un point de contrôle d’approbation humaine avant l’envoi de toute confirmation de remboursement, car c’est irréversible et financier.
    B. Délimiter le connector à ce dont la tâche a besoin uniquement, puisque la boîte contient des PII clients.
    C. Autoriser l’auto-envoi uniquement quand Claude évalue sa propre confiance comme élevée.
    D. Connecter toute la boîte pour ne rien manquer.
    E. Utiliser un modèle plus gros pour qu’aucun point de contrôle ne soit nécessaire.

    **Réponse : A et B.** Les envois financiers irréversibles ont besoin d’un point de contrôle humain, et les connectors doivent suivre le moindre privilège car la boîte contient des PII. La confiance auto-évaluée (C) n’est pas un point de contrôle valide (dépendance à l’auto-déclaration) ; connecter toute la boîte (D) surexpose ; la taille du modèle (E) ne supprime pas le risque.
  </AccordionItem>

  <AccordionItem title="Q15 · Un pilote a réduit le temps de traitement de 40 % avec un CSAT global stable. Le manager veut déployer aux 12 équipes la semaine prochaine. Que doit-il se passer en PREMIER ? (Sélectionnez une réponse)">
    A. Déployer à toutes les équipes immédiatement ; les chiffres sont bons.
    B. Vérifier la qualité par type de tâche et les taux de retouche des relecteurs, puis définir règles de données, points de contrôle de revue et responsabilité avant de phaser le déploiement.
    C. Faire passer tout le monde au modèle le plus cher.
    D. Supprimer la revue pour aller plus vite.

    **Réponse : B.** Le temps et le CSAT agrégé peuvent cacher un segment faible ; vérifiez la qualité par type et mettez la gouvernance en place avant un déploiement par phases. Un déploiement big-bang immédiat (A) saute les deux ; un modèle plus cher (C) est sans rapport ; supprimer la revue (D) est dangereux.
  </AccordionItem>

  <AccordionItem title="Q16 · Quel besoin franchit clairement la frontière d’escalade vers les Developers/Architects ? (Sélectionnez une réponse)">
    A. Un rapport mensuel récurrent avec les mêmes docs de référence, rédigé par une personne dans le chat.
    B. Un pipeline qui ingère des webhooks d’API, extrait des champs et met à jour une base de données automatiquement 24/7 sans humain par exécution.
    C. Itérer sur une proposition dans un artifact.
    D. Rédiger une prise de contact personnalisée avec un connector CRM délimité.

    **Réponse : B.** Un traitement automatique, de système à système, non supervisé 24/7 a besoin d’une intégration conçue — territoire Developer/Architect. Les autres gardent un humain dans la boucle et restent en zone utilisateur métier.
  </AccordionItem>

  <AccordionItem title="Q17 · Une partie prenante veut que l’Associate promette que le nouveau flux « fonctionnera pour ainsi dire tout seul ». Quelle est la MEILLEURE réponse ? (Sélectionnez une réponse)">
    A. Être d’accord, pour sécuriser l’adhésion.
    B. Expliquer qu’un humain relit et est responsable des sorties à des points de contrôle définis, décrire la valeur concrète et les limites, et mettre en place un canal de retour.
    C. Dire que le modèle supérieur le rend entièrement autonome.
    D. Refuser de communiquer toute valeur.

    **Réponse : B.** Un cadrage honnête associe une valeur concrète aux limites, à un point de contrôle de revue/responsabilité et à une boucle de retour. Promettre l’autonomie (A, C) surpromet et perd la confiance à la première erreur ; refuser de communiquer la valeur (D) écarte un bénéfice réel.
  </AccordionItem>

  <AccordionItem title="Q18 · Une équipe mesure un pilote uniquement en heures gagnées. Quel est le RISQUE, et la correction ? (Sélectionnez une réponse)">
    A. Aucun risque ; les heures gagnées sont la seule métrique qui compte.
    B. Les heures gagnées peuvent masquer une perte de qualité et de la reprise ; mesurez aussi les taux d’erreur/retouche par type de tâche.
    C. Ils devraient mesurer les inscriptions à la place.
    D. Ils devraient arrêter de mesurer une fois le temps baissé.

    **Réponse : B.** Une métrique de temps seule peut cacher des régressions de qualité et de la reprise ; des métriques de qualité par type de tâche complètent le tableau. Le temps n’est pas la seule métrique (A) ; les inscriptions (C) mesurent l’adoption, pas la qualité ; arrêter de mesurer (D) supprime la preuve nécessaire à la mise à l’échelle.
  </AccordionItem>

  <AccordionItem title="Q19 · En cartographiant un flux de traitement de sinistres, quelles DEUX étapes devraient rester ENTIÈREMENT humaines ? (Sélectionnez deux réponses)">
    A. Approuver ou refuser le versement d’un sinistre.
    B. Résumer les documents justificatifs.
    C. Envoyer la lettre de décision finale au client.
    D. Reformater les notes de sinistre en tableau.
    E. Rédiger un résumé interne du sinistre.

    **Réponse : A et C.** Une décision de versement et l’envoi d’une lettre de décision externe et irréversible sont des étapes humaines conséquentes. Résumer (B), reformater (D) et rédiger des notes internes (E) sont des étapes réversibles et fortes en langage que Claude assiste sous revue.
  </AccordionItem>

  <AccordionItem title="Q20 · Un Associate planifie le déploiement d’un pilote validé. Quelle séquence reflète une mise à l’échelle responsable ? (Sélectionnez une réponse)">
    A. Mettre à l’échelle à toute l’organisation d’abord, puis mesurer et ajouter la gouvernance si des problèmes apparaissent.
    B. Mesurer contre une référence, standardiser dans des Projects/Skills, ajouter règles de données/points de contrôle/responsabilité, puis phaser le déploiement avec une mesure continue.
    C. Standardiser sur le modèle le plus cher et supprimer la revue pour aller vite.
    D. En garder un pilote mono-équipe permanent sans documentation.

    **Réponse : B.** Une mise à l’échelle responsable mesure, standardise, gouverne, puis déploie par phases avec supervision. Mettre à l’échelle avant la gouvernance (A) est dangereux ; le modèle le plus cher plus l’absence de revue (C) surdimensionne et supprime les garde-fous ; ne jamais mettre à l’échelle ni documenter (D) renonce à la valeur et à la reproductibilité.
  </AccordionItem>
</Accordions>

## À retenir
- Placez Claude sur les étapes de rédaction/synthèse/analyse fortes en langage et réversibles ; gardez les humains sur les décisions et les actions irréversibles.
- Cartographiez d’abord tout le processus, puis placez Claude et insérez des points de contrôle de revue selon le risque.
- La profondeur de la supervision humaine évolue avec les enjeux ; les actions irréversibles/réglementées ont toujours besoin d’un point de contrôle d’approbation humaine.
- Les connectors font entrer les données de vos outils — et leur sensibilité — dans le périmètre ; appliquez le moindre privilège.
- Escaladez vers les Developers/Architects tout ce qui doit s’exécuter automatiquement, s’intégrer de système à système ou agir de façon autonome.
- Communiquez une valeur concrète et des limites honnêtes ; les humains sont responsables de la sortie.
- Mesurez le temps gagné, la qualité (par type de tâche) et l’adoption ; pilotez sur un processus à faible risque, ajoutez la gouvernance, puis mettez à l’échelle.
- Routez chaque besoin par l’arbre construire-ou-escalader : aucun humain par exécution ⇒ escalader.
- L’adoption a besoin de formation, de responsabilité et d’une boucle de retour, pas seulement d’un outil fonctionnel.
- Ajoutez la gouvernance avant le déploiement large et phasez le déploiement plutôt qu’un lancement big-bang.