Récapitulation et examen final

Dix modules pour passer d'un agent unique à une équipe multi-agents qui livre — et sait quand ne pas se déployer. Voici le cours condensé, puis les fils qui le traversent.

Le cours d'un coup d'œil

Module	L'essentiel à retenir
1. Un ou plusieurs agents	Agent unique bien consigné = référence à battre ; équipe pour séparer rédaction/relecture, spécialiser, arbitrer
2. Agents, rôles, objectifs	Rôle, but, biographie = prompt système structuré ; objectif falsifiable, un modèle par agent selon le besoin
3. Tâches et résultats	expected_output = contrat entre tâches ; seule la sortie finale traverse, context=[…] rend les dépendances explicites
4. Séquentiel ou hiérarchique	Séquentiel = ordre fixe, prévisible, économique ; hiérarchique = gestionnaire qui arbitre, cher et variable — réservé aux problèmes ouverts
5. Outils partagés	Outils à l'agent pour la compétence permanente, à la tâche pour l'usage ponctuel ; moindre privilège pour la qualité et la sécurité
6. Délégation et supervision	allow_delegation=False par défaut ; boucles = objectifs trop proches ou aucune autorité de conclusion ; responsable qui ne délègue pas
7. Mémoire commune	Mémoire ≠ context ; courte / longue / entités ; désactivée par défaut, activée sur cas précis ; persistée sur disque sans ACL
8. Coût et limites	12 à 40 appels LLM par exécution ; latence en dizaines de secondes ; asynchrone, pas interactif ; plafonds contexte, quota, monétaire
9. Débogage	Trois lectures : entêtes, outils, Final Answer ; le geste qui débloque = rendre l'expected_output mesurable
10. Projet	Équipe à quatre agents, séquentiel, dix exécutions pour valider ; comparaison honnête équipe / agent seul / humain

Les fils qui traversent le cours

L'agent unique est la référence à battre, pas à mépriser. Chaque module a rappelé que multiplier les agents multiplie le coût, la latence et la variabilité. Une équipe ne se justifie que par un défaut identifié — séparation rédaction/relecture, spécialisation par domaine, arbitrage — et jamais par principe. Le module 8 chiffre l'écart : environ un facteur cinq entre un agent unique et une équipe de quatre pour le même livrable brut. Le facteur devient un investissement rentable quand la qualité mesurable augmente ; sinon, c'est du gaspillage.

La précision de la sortie attendue pilote tout. Le module 3 l'introduit, le module 9 le confirme par le débogage : la quasi-totalité des équipes qui « ne marchent pas » ont des expected_output vagues. Un adjectif dans une sortie attendue est une bombe à retardement. Chaque adjectif — « claire », « pertinente », « structurée » — doit devenir un critère mesurable : nombre de sections, bornes de mots, champs obligatoires, exclusions explicites. C'est le seul travail dont le retour sur investissement dépasse celui d'un changement de modèle.

Séquentiel par défaut, hiérarchique sur cas précis. Le module 4 pose la règle : séquentiel quand l'ordre est connu, hiérarchique quand il ne l'est pas. Beaucoup de projets adoptent le hiérarchique par confusion avec la sophistication ; c'est presque toujours une erreur qui triple la facture sans améliorer le livrable. Le hiérarchique ne compense pas des définitions floues, il les amplifie. Corrigez d'abord la chaîne séquentielle.

La délégation amplifie ce qui existe déjà. Le module 6 le résume : allow_delegation=True sur des agents bien définis produit une coopération saine ; sur des agents mal définis, cela produit des boucles. Le remède aux boucles n'est pas de restreindre la délégation ; c'est de différencier les objectifs et de nommer un responsable qui a l'autorité de conclure et ne délègue pas lui-même.

Le débogage est éditorial, pas technique. Le module 9 l'illustre par sa table des cinq pannes : aucune n'est un bogue de code, toutes sont des défauts de définition. Reprendre la description d'une tâche, réécrire un expected_output, resserrer la description d'un outil — ce sont les gestes qui font converger. Aucun try/except n'y suppléera.

Le coût est le juge de paix. Le module 8 impose la discipline : dix exécutions, comptage des jetons, projection à l'échelle réelle avant l'industrialisation. Une équipe qui produit un livrable superbe à 3 $ par exécution est utilisable pour de la production éditoriale à faible volume ; elle est ruineuse pour du traitement de masse. Ce chiffrage doit être annoncé au client dès le prototype, pas découvert à la première facture.

La grille « un agent, une équipe ou un script »

Face à un nouveau cas d'usage, la décision se prend en trois questions dans l'ordre :

1. La tâche est-elle déterministe et sans ambiguïté ? Extraction rigide de champs, calcul, formatage — un script classique ; pas de LLM du tout.
2. La tâche demande-t-elle jugement, style ou synthèse dans un cadre étroit ? Un agent unique bien consigné, avec deux ou trois outils, suffit.
3. La tâche exige-t-elle production, relecture et arbitrage sur un livrable long ? Une équipe CrewAI se justifie — après avoir mesuré ce qu'un agent unique rate.

Cette grille évite deux erreurs symétriques : appeler un LLM pour ce qu'un regex suffit à faire, et déployer une équipe de quatre agents pour ce qu'un agent unique produirait au dixième du coût.

L'examen final

L'examen comporte 40 questions couvrant les dix modules : distinction entre agent unique et équipe, rédaction d'un objectif d'agent, description d'une sortie attendue, choix du processus, attribution des outils, délégation et supervision, mémoire et passage de contexte, calcul de coût, lecture d'une trace, et diagnostic de pannes concrètes.

Plusieurs questions présentent des situations à diagnostiquer : une équipe qui boucle entre le rédacteur et le relecteur, une exécution dont la facture triple sans raison apparente, un livrable qui varie de format à chaque exécution, un outil que l'agent invoque au mauvais moment. C'est le jugement qui est évalué, pas la récitation.

En cas de réussite, votre attestation d'achèvement est délivrée immédiatement ; son numéro est vérifiable par tout tiers sur la plateforme.

Avant de commencer

Reprenez le tableau ci-dessus et, pour chaque ligne, demandez-vous « comment verrais-je que je me trompe ici ? ». Si vous savez dire pourquoi une équipe hiérarchique triple la facture sans améliorer le livrable, pourquoi deux agents avec le même objectif finissent en boucle, et ce qu'une expected_output vague coûte réellement, vous êtes prêt. Bonne chance !

Examen final

Prêt à valider ce cours ?

40 questions tirées au hasard dans la banque du cours · seuil de réussite 70 % · certificat PDF vérifiable délivré immédiatement en cas de réussite.

Commencer l'examen

Connexion à votre compte InSkillML et abonnement actif requis. Vous pouvez aussi lancer l'examen depuis Mes cours.