Créer un agent de design fiable, du brief au fichier validé
Un agent de design doit livrer un fichier que l’équipe peut relire, corriger et utiliser. Pour y parvenir, il lui faut des règles de marque accessibles, des outils de création et des critères pour vérifier son travail. Son autonomie se construit à partir de ce qu’il sait accomplir de façon répétable.
Dans cet article
Donner de l’autonomie là où une décision est nécessaire
Pour décliner un titre approuvé dans un modèle fixe, un script peut suffire. Un agent devient utile lorsque la demande exige de chercher une référence, de choisir une composition et de corriger le résultat après inspection. L’agentivité désigne cette capacité à décider de l’action suivante.
Anthropic distingue les workflows prédéfinis des agents qui choisissent leur parcours et leurs outils. Dans un système de design, je recommande de réserver ce choix aux étapes qui en ont besoin. Les dimensions d’export ou la présence d’un champ obligatoire peuvent être contrôlées par du code.
Décrivez d’abord une mission complète : produire un brouillon d’annonce à partir d’une bibliothèque approuvée, puis enregistrer sa source éditable. Cette mission donne un résultat observable pour décider si l’autonomie accordée est utile.
Écrire un contrat de mission observable
Commencer par une mission délimitée : produire un brouillon de visuel d’annonce à partir d’un brief et d’une bibliothèque approuvée. Préciser les entrées obligatoires, les ressources accessibles, les formats acceptés et les actions interdites sans accord. Le contrat doit aussi expliquer quand demander une information.
Si la demande contient un chiffre non sourcé, l’agent doit le signaler. Si aucun modèle ne convient, il peut proposer une piste soumise au designer plutôt que forcer une composition. Limiter la durée, le nombre d’essais ou le budget empêche une boucle de corrections sans fin. Un arrêt explicite est parfois un meilleur résultat qu’un fichier médiocre livré avec assurance.
Séparer le contexte, les outils et les permissions
Le contexte explique la marque et le besoin. Les outils permettent de lire, composer, enregistrer et exporter. Les permissions déterminent ce qui est autorisé. Ces trois couches doivent rester distinctes : connaître une consigne de publication ne doit pas accorder automatiquement le droit de publier.
Le Model Context Protocol permet notamment d’exposer des ressources et des outils à une application d’IA. Il ne remplace ni les règles de marque ni la validation d’un résultat. Le cas Gladia illustre une bibliothèque reliée à la création par un Design MCP ; la qualité dépend aussi de ce que cette bibliothèque décrit et des contrôles du parcours.
Donner à chaque étape une preuve de réussite
Une réponse « terminé » ne suffit pas. L’agent doit pouvoir distinguer les états et fournir une preuve adaptée. Voici un contrat de livraison que je recommande pour un premier système, à adapter aux outils employés.
| État | Preuve attendue | Contrôle |
|---|---|---|
| Brief compris | Champs et informations manquantes identifiés | Cohérence avec la demande |
| Brouillon composé | Aperçu inspectable | Texte, hiérarchie, débordements |
| Source enregistrée | Fichier rouvert ou ressource relue | Persistance et éditabilité |
| Export produit | Fichier final accessible | Format, dimensions, intégrité |
| Livrable validé | Accord sur cette version | Contenu et direction visuelle |
| Publication | Autorisation puis résultat vérifié | Destination et version correctes |
La validation doit porter sur une version identifiable. Si l’agent modifie le fichier après l’accord, cette nouvelle version ne doit pas hériter silencieusement de l’approbation précédente. De même, un contenu récupéré dans une page ou un document sert de donnée ; il ne doit pas pouvoir élargir les permissions de l’agent.
Mesurer la fiabilité sur des cas reproductibles
La reliability, ou fiabilité, se mesure sur des tâches représentatives et répétées. Constituer un ensemble de briefs avec résultats attendus : demande ordinaire, titre long, asset absent, instruction contradictoire, export impossible et demande hors périmètre. Exécuter ces cas lorsqu’un modèle, un outil ou une règle change.
Suivre séparément la réussite technique, l’acceptabilité visuelle, l’exactitude du contenu et les actions non autorisées. Une moyenne unique masque les erreurs graves. Conserver le brief, la version des règles, les outils appelés et la raison d’un échec permet de corriger le bon niveau. Documentez les résultats par type de demande. Ils serviront à choisir les usages qui peuvent devenir autonomes et ceux qui doivent encore être relus.
Faire intervenir le designer aux décisions qui engagent la marque
Le human in the loop consiste à placer une personne dans le circuit de décision. Pour un agent de design, les moments utiles sont une direction nouvelle, une affirmation non vérifiée, une exception de marque et l’approbation du livrable destiné à la diffusion. Ces arbitrages doivent être prévus avant que l’agent commence.
Le relecteur reçoit la version à approuver, les sources utilisées et les points encore incertains. Il doit pouvoir demander une correction précise et retrouver ensuite le fichier modifié. Si le livrable évolue après son accord, la nouvelle version repasse par la validation appropriée.
Pour lancer un premier agent, choisissez un format courant et un petit ensemble de briefs représentatifs. Vérifiez la création, la sauvegarde, la retouche et l’export. Augmentez son périmètre lorsque ces étapes fonctionnent de manière répétée : l’équipe saura alors ce qu’elle peut lui déléguer et quand reprendre la main.
