Workflows de parallélisation

Deuxième pattern de workflow après l’évaluateur-optimiseur : la parallélisation. Son terrain d’application, ce sont les tâches qui demandent à Claude de jongler avec plusieurs analyses simultanées — plusieurs angles d’expertise sur un même objet. Plutôt que d’exiger tout d’une seule requête, on découpe, on exécute en parallèle, on agrège.

Le problème des requêtes complexes uniques

Imaginons une application qui recommande des matériaux pour des pièces industrielles : l’utilisateur soumet la photo d’une pièce, et le système doit dire si elle devrait être usinée en métal, moulée en polymère ou frittée en céramique. Envoyer une seule requête listant tous les critères de chaque famille de matériaux — propriétés mécaniques, coûts, contraintes de fabrication, pour dix candidats — crée un prompt énorme qui peut noyer Claude. On retrouve la leçon des prompts spécifiques : plus une requête empile d’exigences hétérogènes, plus le modèle risque d’en traiter certaines superficiellement. Une analyse à dix volets faite d’un bloc, c’est souvent dix analyses médiocres.

L’approche parallélisée

La parallélisation renverse la construction : au lieu de tout mettre dans une requête, on envoie la même image à Claude plusieurs fois, avec des prompts spécialisés différents — une requête analyse la pertinence du métal, une autre évalue les options en polymère, une troisième considère les matériaux céramiques, et ainsi de suite. Chaque prompt est hautement spécialisé pour son matériau : il peut détailler les critères propres à sa famille, citer les nuances d’alliages ou de polymères pertinentes, exiger un format d’analyse précis. Chaque instance de Claude ne porte qu’une seule casquette d’expert — et la porte bien. Comme ces requêtes sont indépendantes les unes des autres, rien n’oblige à les exécuter l’une après l’autre : elles partent en parallèle, et l’analyse complète ne dure que le temps de la plus lente.

Agrégation des résultats

Une fois toutes les analyses individuelles reçues, une requête finale à Claude joue le rôle d’agrégateur : elle reçoit les rapports spécialisés — l’avis « métal », l’avis « polymère », l’avis « céramique » — les compare, arbitre leurs conclusions éventuellement contradictoires et produit la recommandation finale. Ce dernier appel travaille sur des synthèses courtes et structurées, pas sur le problème brut : c’est un prompt de comparaison, bien plus simple que le prompt monolithique qu’on cherchait à éviter.

Le pattern général

Abstrait de l’exemple, le motif tient en trois verbes :

1. Diviser une tâche complexe en sous-tâches spécialisées
2. Exécuter les sous-tâches en parallèle
3. Agréger les résultats dans une étape finale

Les bénéfices se cumulent. L’attention est focalisée : Claude se concentre sur une analyse à la fois, avec la profondeur que la requête unique diluait. L’optimisation est facilitée : chaque sous-prompt s’évalue et s’améliore indépendamment — si l’analyse polymère est faible, on la retravaille sans toucher au reste. L’extensibilité suit : ajouter une famille de matériaux, c’est ajouter une requête parallèle, sans complexifier les sous-tâches existantes. Et la rapidité vient en prime : l’exécution parallèle réduit le temps total par rapport au même travail en séquence.

Le choix entre chaînage et parallélisation découle de la structure de dépendance : des étapes qui se nourrissent l’une l’autre se chaînent ; des analyses indépendantes du même objet se parallélisent. Les workflows réels combinent souvent les deux — des branches parallèles à l’intérieur d’une chaîne.

Points clés à retenir

• Une requête unique surchargée d’angles d’analyse produit des analyses superficielles
• Parallélisation : même entrée, N prompts spécialisés indépendants, exécutés simultanément
• Une requête d’agrégation finale compare les rapports et produit la recommandation
• Chaque sous-tâche s’optimise isolément ; en ajouter une ne complique pas les autres
• Dépendances séquentielles → chaînage ; analyses indépendantes → parallélisation — et les deux se combinent