L’IA dans le produit avec un bon Design System et des Skills.

Cet article est dédié à l’IA dans le produit, avec un Design System et des Skills. Il résume le meet-up du 2 juillet 2026 sur le sujet. Vous pouvez voir le replay ici.

Vous savez que vous devriez vous mettre à l’IA. Mais tout va trop vite, et vous ne savez pas par où commencer. Les Skills sont une porte d’entrée concrète : un simple dossier de fichiers markdown qui transmet votre savoir-faire à un agent IA. Au meet-up du 2 juillet, nous avons montré la différence, démos à l’appui : une maquetteReprésentation visuelle statique de l'interface d'un produit ou service, souvent utilisée pour visualiser et valider les concepts initiaux. More FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More conforme au pixel, des specs d’accessibilité alignées sur le RGAA, du code qui respecte vos conventions. Voici l’intégralité de ce que nous avons partagé.

---

Dans les équipes produit, nous sommes tous dans une bulle IA

L’anxiété liée à l’IA est réelle dans les équipes produit. Tout évolue à une vitesse folle. Vous voulez apprendre, mais vous n’avez pas le temps, et ça ressemble à une montagne.

Sur LinkedIn, tout le monde semble expert et fait « des trucs de fou ». La réalité des équipes est plus nuancée. Et pour un profil non technique, la première ouverture d’un terminal reste un atterrissage sur une autre planète.

Ce meet-up visait une chose : mettre le pied à l’étrier à tout le monde. Si vous êtes designer et que vous regardez Claude Code en pensant « c’est puissant, mais je ne sais pas gérer tout ça », lisez la suite.

Un avertissement honnête d’abord. Cet article est un instantané de nos pratiques en juin 2026 : certaines informations deviendront obsolètes. La réflexion sous-jacente, elle, perdurera. Comment organiser les compétences, découper les contenus, structurer les connaissances pour qu’elles évoluent, avec les outils, de manière agnostique, en gardant l’humain au centre.

C’est d’ailleurs notre positionnement IA chez Frontguys : une IA cadrée (l’IA assiste, l’humain décide et contrôle les résultats), pertinente (des cas d’usage qui apportent une vraie valeur, en complément de l’expertise humaine) et raisonnée (des modèles adaptés aux besoins réels, économes, sans dépendance à un outil ou un fournisseur). Tout le sujet du meet-up tient dans cette dernière ligne : travailler avec l’IA quel que soit le modèle, quel que soit l’outil.

Une skill, c’est quoi ?

Les Skills sont un format ouvert et léger permettant d’étendre les capacités des agents IA avec des connaissances spécialisées et des workflows dédiés. agentskills.io

Pourquoi c’est utile ? Parce qu’un LLM fait des moyennes. Il a une bonne connaissance générale, mais reste un modèle probabiliste. Sans règles d’usage précises, le résultat est aléatoire.

Pour s’amuser sur un projet perso, c’est acceptable. Dans une organisation qui doit respecter des standards et industrialiser, il faut des workflows dédiés. C’est exactement ce que les skills apportent.

La spécification a été écrite par Anthropic, puis publiée en ouvert. Elle a été reprise très vite : FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More, Copilot, OpenAI et bien d’autres. Il existe quelques différences mineures entre éditeurs, mais le format est portable à 80-90 %. C’est devenu un standard de fait.

La démo : avec et sans skills

Nous avons fait trois démos, pour couvrir le workflow complet : design, accessibilité, code. Le point de départ : la page contact de notre site dédié à l’accessibilité, telle qu’elle existe en production. Tout est public dans le repo de démo, prompts, skills et résultats générés, avec deux branches de test (Sonnet et Opus).

Design : de la page ratée à la page conforme au pixel

Sans skills. Nous avons donné à Claude l’URL de la page en inspiration, avec pour consigne de construire la page contact dans FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More. Résultat : complètement raté. La maquetteReprésentation visuelle statique de l'interface d'un produit ou service, souvent utilisée pour visualiser et valider les concepts initiaux. More ne ressemble pas à l’original. Aucune variable, aucun composant lié, le check de design de FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More le confirme : rien ne va.

Au passage, une leçon utile : même quand on lui interdit, Claude a tendance à fouiller sa mémoire et son cache pour « s’inspirer ». Sans cadre, le résultat est biaisé par des restes d’ailleurs.

Avec skills. Un seul prompt : « construis une page contact en te basant sur les skills présents dans mon dossier ». Aucun autre contexte, aucun détail, tout est dans les skills. Résultat : la page ressemble à l’original « comme une goutte d’eau ».

Surtout : rien à revoir. Les calques sont nommés proprement. Pas une seule couleur en dur. Les bons composants sont utilisés, aux bons endroits. Et l’agent peut décliner tous les états du formulaire dans la foulée.

« Il a fabriqué la page aussi bien que je l’aurais fait. Et mieux que beaucoup de designers qui n’ont pas le temps, en mission, de faire ça proprement. »

Dernier test, qui confirme l’approche agnostique : FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More a récemment sorti son propre agent, avec la possibilité d’ajouter des skills à la configuration. Mêmes skills, autre outil : la page générée respecte la charte à 99,9 %, et le check de design ne remonte rien.

Accessibilité : des specs RGAA fiables et des annotations posées dans la maquette

En tant que consultant accessibilité, Hamza intervient avant le développement : specs dans les tickets Jira, ou annotations de développement directement dans FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More (attributs HTML, comportement clavier, restitution par les lecteurs d’écran).

Sans skills. L’agent part sur les WCAG, le référentiel international, alors que le contexte français impose le RGAA. Il suppose la conformité d’éléments qu’il n’a pas vérifiés, contrastes en tête. Le niveau de détail ne permet pas d’en faire des critères d’acceptance exploitables dans un ticket. Et impossible de savoir si les numéros de critères cités sont réels ou hallucinés.

Avec skills. Premier changement, avant même de produire : l’agent pose des questions fonctionnelles. La validation du formulaire se fait-elle en AJAX ou par rechargement ? Ce bouton est-il un lien vers une page ou une action sur place ? Chaque réponse a un impact direct sur les specs d’accessibilité. Pour chaque question, il formule des hypothèses et recommande la réponse la plus probable.

Ensuite, il produit des specs formatées, liées au bon référentiel et aux bons critères RGAA, avec l’interdiction explicite d’inventer un critère de mémoire, et l’obligation de vérifier. Il ajoute des recommandations de code et la méthode de test (exemple : valider les liens d’évitement à la tabulation). Le consultant peut cocher directement sa grille d’évaluation.

Enfin, l’agent utilise l’API de FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More pour poser des annotations natives au bon endroit, reliées au bon composant. Et le niveau de détail s’adapte : une skill peut caler ses specs sur le niveau du développeur qui les recevra, novice ou aguerri en accessibilité.

Ce filet de sécurité contre l’hallucination, c’est exactement ce qui manque quand on fait de la conformité. Vous imaginez le temps gagné ?

Code : vos conventions, pas celles du modèle

Sur le code, la différence est moins spectaculaire, et c’est une info en soi. Dans les deux cas, l’agent partait d’une maquetteReprésentation visuelle statique de l'interface d'un produit ou service, souvent utilisée pour visualiser et valider les concepts initiaux. More extrêmement bien spécifiée, visuellement et en accessibilité, via le MCP de FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More. Les résultats d’accessibilité sont très bons dans les deux cas, principalement parce que les specs étaient excellentes.

Sans skills : du CSS natif correct, mais en vrac. Gestion des états d’erreur inline, code dur à lire, allers-retours permanents entre le fichier CSS et le HTML, pas d’autocomplétion.

Avec skills : le code respecte les conventions choisies. CSS modules pour l’autocomplétion, sous-composants nommés précisément, et une librairie dédiée pour gérer les styles liés aux variants d’un composant. C’est tout l’enjeu en entreprise : une base de code a des conventions et des librairies existantes, et l’agent doit les suivre.

Sur le choix de modèle : les tests ont tourné avec Sonnet (modèle intermédiaire, autonomie maximale) et Opus. Pour générer du front, Sonnet suffit largement. Inutile de payer le dernier modèle pour du HTML.

Pourquoi créer vos propres skills

Trois bénéfices structurent notre usage :

• Capitaliser sur vos connaissances et pratiques, ce que vous et votre équipe avez déjà documenté.
• Guider, uniformiser et fiabiliser les résultats. Sans skill, deux personnes obtiennent deux résultats différents pour la même demande.
• Industrialiser le partage de connaissance.

Et quatre terrains d’application :

1. Vos outils (CLI, API, MCP) – une skill avec la documentation et des instructions pas à pas évite les erreurs.
2. Vos process – guidelines, contrôles qualité, création de tickets : un template et une checklist produisent du contenu qui vous ressemble.
3. Vos modèles – trop bavard, toujours d’accord, accroché à une stack unique : une skill compense ces biais.
4. Vos usages – brainstorm, review, production… et même les recettes de pâte à pizza. Une skill n’a pas besoin d’être sérieuse pour être utile.

Anatomie d’une skill : un dossier d’expertise

nom-de-skill/
├── SKILL.md      # obligatoire : métadonnées + instructions
├── references/   # optionnel : doc, guides, specs
├── assets/       # optionnel : templates, images
└── scripts/      # optionnel : code exécutable

SKILL.md est le seul fichier requis. Du markdown : un format texte léger, lisible par tous, non propriétaire. Le tout est versionnable, historisé et auditable via git, compatible avec tous les agents, et découvrable par eux à l’exécution.

Le fichier a deux parties. Les métadonnées : le nom (celui du dossier, minuscules et tirets) et surtout la description. Elle ne décrit pas la skill pour un humain : elle dit à l’agent quand se déclencher, avec quels mots-clés. C’est la métadonnée la plus importante du système. S’y ajoutent des options : allowed-tools (outils pré-approuvés) et des extensions par éditeur comme disable-model-invocation.

Le contenu ensuite : la posture à tenir (« agis en tant qu’expert de X »), les instructions étape par étape, les templates et formats de réponse, des exemples pour contextualiser, et la gestion des cas particuliers.

La règle essentielle : les modèles savent déjà beaucoup de choses. Concentrez-vous sur ce que l’agent ne peut pas savoir : vos conventions, vos procédures, vos outils. Et dire quoi ne pas faire est aussi important, sinon plus, que dire quoi faire.

Sous le capot : la skill qui produit nos pages Figma

Prenons la skill de la démo design : design-landing-page. Elle n’est pas monolithique — elle orchestre cinq skills. design-system (tokens, composants, protocole de liaison des variables), design-frontguys (ton, discours, personas de la marque), figma-use (l’API FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More), design-web-section (les sections réutilisables du site), et elle-même comme chef d’orchestre.

Pourquoi ce découpage ? Le coût. Réduire la consommation de la fenêtre de contexte est un des vrais problèmes des années à venir. Le découpage permet de ne charger que le nécessaire : nos premières versions non optimisées consommaient 30 000 à 40 000 tokens pour produire une page. Aujourd’hui : environ 5 000.

Le workflow suit trois phases. Cadrage : l’agent pose des questions quand il lui manque des informations. Architecture : il propose la structure, et un humain valide avant production. Production FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More : import du design system, assemblage section par section.

Six règles non négociables encadrent le tout, vérifiées par un « pre-flight check » automatique avant livraison :

1. Aucune valeur en dur – couleur, spacing, radius, font : tout est lié à une variable du DS.
2. Composants = instances – jamais reconstruits, toujours importés.
3. Voix déléguée – jamais de règle de ton de mémoire, citation de la source obligatoire.
4. Hiérarchie stricte – H1, H2, priorité des CTA, pas de doublon d’action principale.
5. Illustrations = instances du DS – chaque illustration est nommée et décrite, pour que l’agent choisisse la bonne selon le contexte.
6. Zéro défaut au pre-flight check – l’agent prend un screenshot de ce qu’il a produit, vérifie, et corrige lui-même ses erreurs.

Des instructions efficaces : quatre précisions qui changent tout

1. Les pièges à éviter. Pas des conseils généraux : des corrections concrètes aux erreurs spontanées de l’agent, constatées par expérience. Commencez avec trois ou quatre points évidents, enrichissez au fil des ratés.
2. Le format de sortie. Un modèle à suivre est plus fiable qu’une description. Les templates courts vivent dans SKILL.md, les longs dans assets/.
3. La boucle de validation. Effectuer le travail, exécuter un validateur, corriger, répéter. Le validateur va du simple (une auto-vérification demandée à l’agent) au strict : un script embarqué, le compilateur TypeScript, des tests, du déterministe, qui passe ou ne passe pas. On peut même mobiliser un second agent en critique.
4. Planifier-valider-exécuter. Pour les opérations par lots ou destructives : l’agent crée un plan structuré, le fait valider, puis l’exécute.

Le nerf de la guerre : le chargement et le contexte

Les agents ne chargent pas tout en amont. C’est le principe de divulgation progressive, en trois niveaux :

• Niveau 1 – le nom et la description. C’est tout ce que l’agent voit au départ. D’où l’investissement sur la qualité de la description.
• Niveau 2 – le contenu de SKILL.md, chargé si la tâche le justifie.
• Niveau 3 – les ressources (references/, scripts/, assets/), chargées à la demande. Le fichier principal contient un index : « si tu dois faire X, va chercher telle référence ».

Nos repères pratiques :

• Une description travaillée (~5 à 10 lignes) qui ne déclenche la skill que quand elle est utile.
• Des instructions sous les 500 lignes. Au-delà, découpez : plusieurs skills, ou des références chargées à la demande.
• Des outils cohérents : si la skill demande de vérifier un contraste de couleur, l’agent doit avoir l’outil pour prélever une couleur (MCP ou script). Sinon il supposera, ou inventera.
• Vérifiez l’espace consommé : /skills et /context dans Claude, System Instructions dans Copilot CLI.

Parlons coût, honnêtement. Sur notre démo code, la génération sans skills a consommé environ 90 000 tokens et 60 appels d’outils. Avec skills : environ 140 000, soit 60 % de plus, à cause des boucles de vérification. C’est le prix de la qualité et du contrôle. Mais le calcul ne s’arrête pas au premier jet : un premier jet de bonne qualité évite les boucles de correction qui n’en finissent pas, et chaque échange renvoie toute la discussion au modèle. Mieux vaut dépenser un peu plus au départ que corriger longtemps.

Dernier point de vigilance : la fenêtre de contexte. Passé la moitié de sa capacité, un modèle commence à perdre en qualité, comme un livre dont on retient bien le début et la fin, mal le milieu. Et la compression automatique des longues sessions est une compression avec perte. D’où une recommandation : une dizaine de skills actives par projet, pas plus. Trop de skills chargées, c’est plus de conflits et d’hallucinations.

La méthode : se lancer, itérer, synthétiser

Le point le plus important à comprendre pour passer le cap : l’IA est très forte pour vous accompagner dans la fabrication de vos skills. Personne n’écrit tout seul des heures durant. Pas de syndrome de l’imposteur : l’agent analyse ce que vous avez fait, vous testez, vous optimisez, vous itérez. Nos skills représentent plusieurs mois d’itérations.

1. Initier – Partez d’un besoin concret, d’une tâche précise. Exécutez-la avec l’agent. Fournissez un premier niveau d’information : votre documentation existante, des sources, des exemples.
2. Affiner – Variez les prompts, les formats, la posture, le niveau d’exigence. Jouez avec les modèles.
3. Sauvegarder – Demandez à l’agent de synthétiser la session de travail en une ou plusieurs skills. Relisez, découpez, simplifiez.
4. Architecturer – Intégrez à vos skills existantes. Validez le déclenchement, la pertinence et la qualité.

L’astuce des modèles. Faites la première passe avec le modèle le plus avancé sous la main : il propose un plan, utilise les outils correctement, s’auto-analyse et vous aide à déboguer. Puis simplifiez et testez avec le modèle léger que vous utiliserez au quotidien. Beaucoup de nos skills ont été écrites avec Opus, puis simplifiées et validées avec Sonnet. En cas de doute, demandez au modèle lui-même quel modèle convient à la tâche.

Deux skills pour écrire des skills. Celle de Matt Pocock : minimaliste, parfaite pour créer un petit outil rapidement. Et le skill-creator d’Anthropic : complet, avec outillage. Il vous pose des questions sur l’objectif et le déclenchement, puis génère la skill.

Le benchmark, pour savoir si ça marche. Le skill-creator embarque deux outils qui génèrent un rapport HTML – ça tourne sur n’importe quelle machine :

• Benchmark de performance : l’outil analyse la skill, génère une liste d’assertions à vérifier (que vous pouvez éditer avant validation), puis fait tourner les mêmes prompts avec et sans la skill. Résultat en pourcentage. Notre meilleur cas : 30 % de réussite sans la skill, 100 % avec. Plus couramment : 60 % sans, 95 % avec. Très utile aussi après une réorganisation des fichiers, pour vérifier qu’aucun lien de référence n’est cassé.
• Benchmark de description : l’outil génère une liste de demandes simples, chacune marquée « devrait déclencher : vrai/faux », puis vérifie que votre description déclenche la skill au bon moment – et seulement au bon moment.

Le déclenchement, justement. Certaines skills ne se déclencheront jamais toutes seules : le modèle considère qu’il sait déjà faire — c’est presque systématique pour le code. Dans ce cas, invoquez explicitement avec /nom-de-la-skill. À l’inverse, pour réserver une skill à l’invocation manuelle, la métadonnée disable-model-invocation la retire de l’index du modèle (support variable selon les agents ; une description vide produit le même effet).

Et pour entretenir : le prompt de simplification. Les modèles savent déjà énormément de choses, et les skills générées sont souvent trop bavardes. Demandez régulièrement : classe chaque ligne en « garder / réécrire / supprimer », enlève ce que tu sais déjà faire, ne garde que les règles métier et les contraintes spécifiques, et liste ce que tu as changé et pourquoi. Ce prompt, merci Julien Riveron, réduit la taille des fichiers en conservant la performance. Une relecture humaine derrière, et c’est réglé.

Où trouver des skills existantes

Inutile de tout écrire vous-même.

Les sources officielles. Anthropic (dont skill-creator et les skills de production PDF/PowerPoint packagées avec Claude), Figma, Copilot / awesome-copilot (compilation communautaire validée) et OpenAI. Un conseil appuyé pour les skills FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More : n’utilisez jamais le MCP FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More sans elles. Ça fonctionne sans, mais les résultats sont incomparablement meilleurs avec.

Les communautés.

• skills.sh (Vercel) – la référence. Un répertoire en ligne très complet, alimenté automatiquement dès qu’une skill publique est installée via l’outil. Bonus précieux : un auditUn Audit est une évaluation systématique d'un processus ou d'une entité pour vérifier sa conformité, son efficacité ou sa qualité. More de sécurité indique si une skill autorise des actions qu’elle ne devrait pas.
• TypeUI – des patterns visuels décrits finement (« fais-moi un hero », « un bloc de comparaison de prix ») pour vos sessions de génération de maquettes.
• The Designer Skills Suite – des compétences design (research, stratégie, design d’interaction) adaptées aux agents, créées par une designer.
• mcpservers.org/agent-skills – une compilation exhaustive et très bien catégorisée, qui liste aussi les serveurs MCP.

À quoi servent les skills : trois familles d’usage

Spécialiser une tâche — encoder un savoir-faire répétable : la méthodologie d’ingénierie superpowers, le contrôle d’accessibilité WCAG 2.2 d’Addy Osmani, des règles de rédaction, des plans de test complets.

Maîtriser un outil — cadrer les bonnes pratiques et les API : les skills FigmaFigma est un outil de design d'interface en ligne qui facilite la collaboration en temps réel entre les designers. Il offre des fonctionnalités pour le design, le prototypage et la création de systèmes de design. More (FigJam, Slides, Code Connect, diagrammes), Playwright pour piloter un navigateur et vérifier qu’une page correspond à la maquetteReprésentation visuelle statique de l'interface d'un produit ou service, souvent utilisée pour visualiser et valider les concepts initiaux. More, Storybook, Jira pour analyser et construire un backlog.

Corriger un comportement — compenser une faiblesse récurrente du modèle. Les LLM sont bavards et toujours d’accord avec vous. Les skills de Matt Pocock répondent à ça : caveman (réponses courtes), grill-me (l’agent vous challenge au lieu d’acquiescer), grill-with-docs (il vous challenge après avoir lu une référence). Côté BMAD : des reviews en posture critique, cynique, ou pour chasser les cas limites.

Distribuer vos skills

Le chemin de stockage détermine la visibilité, à trois niveaux :

• Personnel – dossier utilisateur : disponible en transversal, dans le chat comme dans les agents. C’est là que nous mettons nos skills de marque, utilisées par designers et développeurs.
• Projet – dossier local du dépôt : partagé avec l’équipe, disponible pour les agents seulement. Le bon endroit pour les skills de production.
• Organisation – un admin peut distribuer des skills à toute l’organisation.

Pour l’entreprise : les plugins. Un plugin regroupe skills, agents, hooks — et souvent des serveurs MCP, car les deux vont ensemble. En doublant les déclarations (un manifeste Claude, un manifeste Copilot), le même plugin fonctionne sur les deux écosystèmes. Un seul repo GitHub peut porter toutes les skills de l’entreprise : la commande /plugin marketplace pointe vers le repo, puis chacun installe son plugin — un pour les designers, un pour les développeurs, un pour les product owners. Découper par métier évite de charger des skills inutiles.

Pour le monde entier : un simple repo GitHub. Pas besoin de marketplace ni de manifeste : des skills correctement formatées dans un dépôt public suffisent. Un npx skills add [owner/repo] les installe dans vos skills personnelles — et les référence au passage sur skills.sh pour tous les autres.

Et l’orchestration d’un workflow métier complet ?

La question est venue de la salle : comment lier plusieurs skills pour reproduire un vrai workflow d’équipe ?

Notre réponse, à date : le moins d’automatisation possible. Sur une mission récente, nous avons commencé par un système ambitieux, plein d’agents et de sous-agents pour accompagner la création d’un design system. Constat : une complexité qui ne servait pas à grand-chose. Nous avons transformé les agents en skills, simplifié au maximum, et basculé sur une invocation explicite, étape par étape : je lance telle tâche, je relis, je valide, la synthèse part dans un fichier, je repars sur une session propre.

Des milliers de lignes divisées par deux ou trois. Des résultats aussi bons, et plus satisfaisants, parce qu’ils correspondent à notre façon de travailler, avec une validation humaine entre chaque étape. Les agents pleinement autonomes ? Nous ne leur faisons pas encore confiance.

Si nous avions un slogan à retenir pour l’IA, c’est vraiment : l’humain dans la boucle.

Ce qui compte vraiment

Les outils changeront, les specs évolueront. Mais structurer votre savoir pour le transmettre, à vos équipes comme à vos agents, est un investissement durable. Notre conviction reste la même : l’IA est un moyen, un accélérateur. Pour être pertinente et efficace, elle doit être cadrée et gouvernée stratégiquement.

Une skill n’est rien d’autre que cela : votre cadre, écrit noir sur blanc, dans un format que tous les agents comprennent.

Pas de la magie. Du savoir structuré.

Et pour sortir de la bulle, on a ouvert un questionnaire maturité et usages de l’IA, 10 questions, 3 minutes :
👉 Vos usages IA – Remplir le formulaire

Toutes les ressources citées sont dans le repo de démo et les slides du meet-up.

Rendez-vous en septembre pour le prochain : gouvernance IA et contrôle des coûts, REX d’un refactoring de dette technique avec Codex, et un serveur IA autonome sur modèles alternatifs.