CrewAI — Sortie structurée : en finir avec la dérive des données grâce à Pydantic

Si vous avez déjà vu une tâche retourner du markdown une fois et un texte libre la fois suivante, vous n'êtes pas seul.
La solution est simple : définir le schéma de sortie avec Pydantic.

Pourquoi une sortie structurée ?

Les tâches en aval peuvent lire des champs fixes
Plus besoin de parsing de chaînes fragile à chaque exécution
Les erreurs sont détectées plus tôt (un champ manquant lève une erreur)

En résumé : c'est un contrat d'API. Une collaboration stable a besoin d'un contrat.

Créer des modèles de sortie

from pydantic import BaseModel, Field
 
class Finding(BaseModel):
    title: str = Field(description="Finding title")
    summary: str = Field(description="Brief explanation")
    source: str = Field(description="Reference URL")
 
class ResearchReport(BaseModel):
    topic: str = Field(description="Topic name")
    findings: list[Finding] = Field(description="Key findings list")
    conclusion: str = Field(description="Final conclusion")

Utiliser `output_pydantic` dans une tâche

from crewai import Task
 
research_task = Task(
    description="Research AI observability tools in 2026.",
    expected_output="Structured research result.",
    output_pydantic=ResearchReport,
)

Après exécution, vous accédez directement aux champs stables au lieu de deviner à partir du texte.

Style de couplage recommandé

Gardez les exigences de qualité dans expected_output explicites
Définissez la sémantique des champs (longueur de summary, format de source)
Faites en sorte que les tâches en aval s'appuient sur les champs, pas sur le style d'écriture

Erreurs courantes des débutants

Penser que Pydantic rend expected_output inutile
Trop peu de champs, donc des infos manquantes
Trop de champs fins, donc des oublis fréquents

⚠️ Commencez avec 3 à 5 champs clés. N'étendez que si besoin.

Prochaine étape

Votre crew unique peut maintenant produire des sorties fiables. Passons à l'orchestration multi-crews.
👉 Bases du Flow