#Pourquoi orchestrer une crew CrewAI en local

Le pattern multi-agents part d'un constat simple : découper une tâche complexe entre plusieurs agents spécialisés donne de meilleurs résultats qu'un unique prompt géant. Chaque agent a un rôle net, un objectif précis, et ne voit que sa part du travail. CrewAI est le framework Python qui formalise ce découpage — rôles, tâches, collaboration séquentielle ou hiérarchique — sans la lourdeur d'un graphe d'états à câbler soi-même.

Faire tourner cette crew sur Ollama plutôt que sur GPT-4 ou Claude change trois choses. D'abord la confidentialité : un pipeline multi-agents multiplie les appels au modèle, donc multiplie les fuites potentielles vers un tiers ; en local, rien ne sort de la machine. Ensuite le coût : une crew bavarde peut brûler des centaines de milliers de tokens par exécution, ce qui devient vite cher sur une API facturée au token — en local le coût marginal est nul. Enfin la maîtrise : vous choisissez le modèle, la quantification, le contexte, et vous itérez sans quota ni rate limit.

À qui s'adresse ce guide

Niveau avancé : on suppose que vous êtes à l'aise en Python, qu'Ollama tourne déjà (daemon sur http://localhost:11434) et que vous avez lancé au moins un modèle. Si l'orchestration d'un agent unique vous manque, le guide LangChain + Ollama pose ces bases avant d'attaquer le multi-agents.

#Les 4 briques de CrewAI

Avant d'écrire une ligne, il faut le vocabulaire. CrewAI repose sur quatre objets qui s'emboîtent. Les comprendre évite 90 % des erreurs de conception d'une crew.

Agent: Un LLM avec une identité : un rôle (« Analyste de marché »), un objectif (goal) et une histoire (backstory) qui cadrent son comportement. Chaque agent peut utiliser son propre modèle Ollama.
Task: Une unité de travail confiée à un agent : une description, un résultat attendu (expected_output) et, souvent, des outils. C'est la tâche, pas l'agent, qui porte l'instruction concrète.
Tool: Une capacité externe qu'un agent peut appeler : recherche web, lecture de fichier, requête SQL, calcul. Sans outils, un agent ne fait que raisonner sur ce qu'il connaît déjà.
Crew: L'équipe : la liste des agents, la liste des tâches, et le process qui décide de l'ordre d'exécution (sequential ou hierarchical). C'est l'objet que vous lancez avec kickoff().

Le process mérite une précision. En mode sequential, les tâches s'exécutent dans l'ordre déclaré et la sortie de l'une nourrit la suivante — parfait pour une chaîne recherche → rédaction → relecture. En mode hierarchical, un agent « manager » (un LLM dédié) délègue et coordonne les autres. Le mode hiérarchique est plus puissant mais bien plus exigeant pour un modèle local, car le manager doit raisonner sur qui fait quoi : commencez toujours par du séquentiel.

#Prérequis et choix des modèles

Ollama fonctionnel: Daemon lancé, endpoint sur http://localhost:11434. Vérifiez avec « ollama list » qu'au moins un modèle capable de tool-use est présent.
Python 3.10+ et un venv: CrewAI se déploie proprement dans un environnement virtuel isolé. Évitez d'installer dans le Python système.
De la VRAM, et de la patience: Le multi-agents enchaîne les appels : chaque tâche = un ou plusieurs allers-retours au modèle. Comptez un modèle 8B minimum, idéalement 14B, pour que le raisonnement tienne.
Un modèle tool-capable: Pour équiper les agents d'outils, il faut un modèle qui gère le function calling : Qwen2.5, Llama 3.1/3.3, Mistral. Un modèle sans tool-use ne peut que raisonner en texte.

Le multi-agents n'est pas magique en local

Une crew multiplie les tokens et les tours de raisonnement. Un modèle 3B qui répond correctement à une question isolée peut s'effondrer dans une chaîne à trois agents : il oublie le contexte, invente des sorties, boucle. Le multi-agents local demande des modèles plus gros que le chat simple. On y revient dans la section modèles.

#Installer CrewAI et le brancher sur Ollama

CrewAI s'installe via pip. Le paquet crewai-tools fournit en prime une bibliothèque d'outils prêts à l'emploi (recherche, fichiers, scraping).

Terminal — installation

# Créer et activer un environnement virtuel
python -m venv .venv
source .venv/bin/activate   # Windows : .venv\Scripts\activate

# Installer CrewAI et sa bibliothèque d'outils
pip install crewai crewai-tools

Le point clé du branchement local : CrewAI s'appuie sur LiteLLM pour parler aux modèles. Pour cibler Ollama, on préfixe le nom du modèle par « ollama/ » et on pointe l'URL de base sur le daemon local. Assurez-vous d'avoir tiré le modèle au préalable.

Terminal — récupérer les modèles

# Un modèle solide et tool-capable pour les agents
ollama pull qwen2.5:14b

# Un modèle plus léger pour les tâches simples (optionnel)
ollama pull llama3.1:8b

Python — configurer le LLM local

from crewai import LLM

# Un LLM CrewAI branché sur Ollama en local
local_llm = LLM(
    model="ollama/qwen2.5:14b",
    base_url="http://localhost:11434",
    temperature=0.3,   # bas = plus déterministe, utile pour une crew
)

→

Baissez la température des agents

En multi-agents, une température élevée fait dériver les agents : ils improvisent au lieu de suivre leur tâche. Une valeur entre 0.2 et 0.4 rend la crew plus fiable et reproductible. Réservez les températures hautes aux tâches purement créatives, isolées dans un seul agent.

#Première crew : définir rôles et tâches

Montons une crew classique et immédiatement utile : un chercheur qui rassemble l'information, puis un rédacteur qui la met en forme. C'est le squelette qu'on réutilise pour la veille, la synthèse documentaire ou la génération de contenu. On définit d'abord les agents, avec des rôles nets.

Python — définir les agents

from crewai import Agent

chercheur = Agent(
    role="Analyste de recherche",
    goal="Rassembler des faits précis et vérifiables sur {sujet}",
    backstory=(
        "Tu es un analyste rigoureux. Tu distingues les faits "
        "des opinions et tu ne retiens que l'information solide."
    ),
    llm=local_llm,
    verbose=True,
)

redacteur = Agent(
    role="Rédacteur technique francophone",
    goal="Produire une synthèse claire et structurée en français",
    backstory=(
        "Tu écris pour un public technique. Tu vas droit au but, "
        "sans jargon inutile ni remplissage marketing."
    ),
    llm=local_llm,
    verbose=True,
)

Le rôle, le goal et la backstory ne sont pas décoratifs : ils constituent le system prompt de chaque agent. Un rôle vague (« Assistant ») donne un agent vague. Soyez spécifiques et donnez une posture — c'est ce qui empêche un petit modèle de sortir du cadre. Notez le placeholder {sujet} : CrewAI l'injecte au lancement depuis les inputs.

Vient ensuite le cœur du travail : les tâches. Chaque tâche pointe un agent, décrit ce qu'il doit produire et, surtout, précise un expected_output. Ce champ est le levier de qualité le plus sous-estimé de CrewAI : plus il est concret, plus la sortie est cadrée.

Python — définir les tâches

from crewai import Task

tache_recherche = Task(
    description=(
        "Recherche les points clés sur {sujet}. Identifie 5 à 7 "
        "faits marquants, chiffrés quand c'est possible."
    ),
    expected_output="Une liste à puces de 5 à 7 faits sourcés et concis.",
    agent=chercheur,
)

tache_redaction = Task(
    description=(
        "À partir des faits rassemblés, rédige une synthèse "
        "structurée de 300 mots sur {sujet}, en français."
    ),
    expected_output="Un texte de ~300 mots avec un titre et 3 sections.",
    agent=redacteur,
    context=[tache_recherche],   # nourrie par la sortie de la recherche
)

Le paramètre context relie explicitement les tâches : la rédaction reçoit la sortie de la recherche. En mode séquentiel, l'enchaînement est déjà implicite, mais déclarer context rend la dépendance lisible et fiabilise le passage d'information. On assemble enfin la crew et on la lance.

Python — assembler et lancer

from crewai import Crew, Process

crew = Crew(
    agents=[chercheur, redacteur],
    tasks=[tache_recherche, tache_redaction],
    process=Process.sequential,
    verbose=True,
)

resultat = crew.kickoff(inputs={"sujet": "les LLM open-weight en 2026"})
print(resultat)

01
Le chercheur s'exécute
Son LLM local reçoit son rôle + la description de la tâche de recherche, et produit la liste de faits attendue.
02
La sortie transite
CrewAI passe le résultat de la recherche comme contexte à la tâche de rédaction, conformément au champ context.
03
Le rédacteur s'exécute
Son agent reçoit les faits et rédige la synthèse de 300 mots, cadrée par son expected_output.
04
kickoff() retourne le résultat final
La sortie de la dernière tâche est renvoyée. verbose=True affiche tout le raisonnement intermédiaire dans le terminal.

#Donner des outils aux agents

Un agent sans outil ne fait que raisonner sur ce que le modèle a déjà en mémoire — vite limité et sujet aux hallucinations. Les outils lui donnent des capacités concrètes : lire un fichier, chercher sur le web, interroger une base. crewai-tools en fournit une série prête à l'emploi, et vous pouvez écrire les vôtres.

Python — un outil intégré et un outil maison

from crewai_tools import FileReadTool
from crewai.tools import tool

# Outil intégré : lire un fichier local
lecteur = FileReadTool()

# Outil maison : décoré avec @tool
@tool("Compteur de mots")
def compter_mots(texte: str) -> int:
    """Compte le nombre de mots d'un texte donné."""
    return len(texte.split())

# On équipe l'agent des deux outils
chercheur = Agent(
    role="Analyste de recherche",
    goal="Analyser des documents locaux sur {sujet}",
    backstory="Tu analyses des sources internes avec rigueur.",
    tools=[lecteur, compter_mots],
    llm=local_llm,
    verbose=True,
)

C'est ici que le choix du modèle devient décisif. Pour utiliser un outil, l'agent doit générer un appel de fonction structuré (function calling) que CrewAI intercepte et exécute. Un modèle qui ne maîtrise pas le tool-use ignorera l'outil ou produira un JSON invalide. Qwen2.5, Llama 3.1/3.3 et Mistral gèrent bien ce mécanisme ; beaucoup de petits modèles génériques non.

Un outil par besoin, pas dix par agent

Chaque outil ajouté agrandit le prompt système de l'agent et complique sa décision. En local, un agent noyé sous dix outils choisit mal, voire boucle. Donnez à chaque agent le minimum d'outils dont sa tâche a besoin — c'est plus fiable et plus rapide.

#Quels modèles locaux tiennent le multi-agents

C'est la vraie question de ce guide. Le multi-agents est bien plus exigeant que le chat : chaque agent doit suivre un rôle, respecter un format de sortie, et souvent appeler des outils — le tout en enchaînant les tâches sans perdre le fil. Un modèle trop petit décroche. Voici les paliers réalistes, en Q4_K_M, avec la VRAM associée.

8B (≈5 Go) — plancher: Llama 3.1 8B, Qwen2.5 7B. Tiennent une crew séquentielle simple à 2 agents avec des outils basiques. RTX 3060 12 Go, RTX 4070. En dessous de cette taille, le multi-agents devient hasardeux.
14B (≈9 Go) — recommandé: Qwen2.5 14B. Le bon compromis : raisonnement solide, tool-use fiable, suit les rôles sans dériver. RTX 4070 12 Go (juste) à RTX 4080 16 Go. C'est le point d'équilibre pour la plupart des crews.
32B (≈19 Go) — confort: Qwen2.5 32B. Encaisse des crews plus longues, des outils multiples, un mode hiérarchique léger. RTX 4090 24 Go, ou Mac M4 Pro en mémoire unifiée. Nettement plus robuste sur les tâches délicates.
70B (≈40 Go) — proche du cloud: Llama 3.3 70B. La qualité de coordination se rapproche des API cloud. Nécessite 48 Go+ : Mac Studio à grosse mémoire unifiée ou multi-GPU. Réservé aux crews ambitieuses.

Astuce d'architecture : rien n'oblige tous les agents à partager le même modèle. Confiez les tâches simples (reformulation, comptage, extraction) à un 8B rapide, et réservez un 14B ou 32B aux agents qui raisonnent ou orchestrent. On instancie simplement deux objets LLM et on les affecte par agent.

Python — modèles différents par agent

gros = LLM(model="ollama/qwen2.5:32b", base_url="http://localhost:11434")
petit = LLM(model="ollama/llama3.1:8b", base_url="http://localhost:11434")

stratege = Agent(role="Stratège", goal="...", llm=gros)
assistant = Agent(role="Assistant", goal="...", llm=petit)

→

Attention au chargement/déchargement

Faire cohabiter plusieurs modèles distincts oblige Ollama à jongler en VRAM : s'ils ne tiennent pas ensemble, il en décharge un pour charger l'autre à chaque bascule, ce qui ralentit la crew. Sur une seule carte, un modèle unique bien choisi est souvent plus rapide que deux qui se battent pour la mémoire.

#Coûts et limites face à une crew sur API cloud

L'argument massue du local, c'est le coût. Une crew est bavarde par nature : chaque agent relit le contexte, raisonne, appelle des outils, et l'expansion du contexte au fil des tâches gonfle le nombre de tokens. Une seule exécution un peu ambitieuse peut consommer des centaines de milliers de tokens. Sur une API facturée au token, un pipeline lancé en boucle pendant le développement devient vite douloureux ; en local, chaque itération est gratuite après l'achat du matériel.

Coût — avantage local: Zéro coût par token. Vous itérez, relancez, déboguez sans compteur qui tourne. Le multi-agents, gros consommateur, est l'usage où le local rentabilise le plus vite le GPU.
Confidentialité — avantage local: Aucun des appels — et ils sont nombreux — ne quitte la machine. Décisif pour du code propriétaire, des données clients ou tout ce qui tombe sous NDA ou RGPD.
Qualité de coordination — avantage cloud: GPT-4 et Claude gèrent le mode hiérarchique, les chaînes longues et le tool-use complexe avec une fiabilité qu'un 14B local n'atteint pas. L'écart se creuse quand la crew se complexifie.
Vitesse — dépend du matériel: Le cloud répond souvent plus vite qu'un GPU grand public sur les gros modèles. Une crew de 4 agents sur un 32B local peut prendre plusieurs minutes par exécution.

La lecture honnête : le local excelle sur les crews séquentielles bien cadrées, où chaque agent a un rôle net et une tâche circonscrite. Il montre ses limites sur l'orchestration hiérarchique ambitieuse, où un modèle de 14B a du mal à jouer le manager qui délègue. La bonne stratégie est souvent hybride — prototyper et faire tourner en local, réserver le cloud aux étapes où la coordination dépasse ce que votre modèle encaisse. Un proxy comme LiteLLM permet précisément de router entre les deux.

#Dépannage

L'agent ignore ses outils: Le modèle ne gère pas le function calling. Passez à Qwen2.5, Llama 3.1/3.3 ou Mistral, et vérifiez que l'agent a bien la liste tools=[...].
« Connection refused » / litellm error: Le daemon Ollama n'est pas lancé ou base_url est faux. Vérifiez « ollama ps » et que l'URL est bien http://localhost:11434.
L'agent boucle ou ne s'arrête pas: Modèle trop petit pour la tâche, ou trop d'outils. Montez en taille (14B min), réduisez le nombre d'outils, baissez la température, et fixez max_iter sur l'agent.
Sorties hors format / expected_output ignoré: Rôle trop vague ou expected_output flou. Rendez-les très concrets, et préférez un modèle 14B+ qui suit mieux les consignes de format.
Crew très lente: Le modèle déborde en RAM/CPU faute de VRAM (« ollama ps » le montre), ou plusieurs modèles se déchargent mutuellement. Descendez d'un cran de taille ou unifiez sur un seul modèle.
Le mode hiérarchique part en vrille: Le LLM manager n'a pas les épaules. Revenez au Process.sequential, ou réservez un 32B+ au rôle de manager.

#Pour aller plus loin

Une crew CrewAI locale s'appuie sur des briques déjà couvertes sur le site. Ces guides prolongent celui-ci :

Créer un agent IA local en Python avec LangChain et Ollama: Les fondations de l'agent unique — outils, boucle de raisonnement — avant de passer au multi-agents.
Function calling et sorties JSON structurées avec Ollama: Pour comprendre le mécanisme de tool-use dont dépendent les outils de vos agents.
LiteLLM : un proxy unifié local et cloud: Pour router une crew entre Ollama local et une API cloud selon la tâche, dans une stratégie hybride.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Développement · 20 min