Des Gems aux Skills : la personnalisation de Gemini devient un flux de travail réutilisable

Illustration éditoriale originale. Elle représente l'idée d'instructions réutilisables, pas une capture d'écran de Gemini ni son architecture interne.

La personnalisation devient l'un des aspects les plus intéressants de l'IA grand public. Un assistant utile ne se contente pas de savoir beaucoup de choses : il se souvient de la manière dont une personne souhaite aborder les tâches récurrentes. Une note de recherche, une révision éditoriale et un passage de relais sur un projet n'exigent pas les mêmes critères. Répéter ces critères dans chaque conversation est fastidieux, et les laisser implicites produit des résultats incohérents.

Le passage de Google des Gems aux Skills répond à ce problème. Au lieu de traiter chaque assistant personnalisé comme une destination entièrement distincte, les instructions réutilisables peuvent s'intégrer à la conversation déjà en cours. Le changement semble minime à l'écran, mais ses conséquences sont plus importantes pour l'organisation des flux de travail. Il entraîne aussi un travail de migration : un ensemble d'instructions familier n'est pas automatiquement bien défini, portable et vérifiable.

Le déploiement varie selon le type de compte

Google prévoit le déploiement des Skills dans l'application Gemini à partir du 13 octobre 2026, avec une finalisation progressive attendue d'ici la mi-novembre. Le déploiement dans Workspace commence le 5 octobre. La mise à disposition est échelonnée : la disponibilité peut donc varier selon le compte. Annonce Google Workspace

Selon la page d'aide de Google, la transition des Gems vers les Skills commence en novembre 2026 pour les comptes personnels. Pour Workspace, elle débutera en mars 2027 pour les comptes Business, Enterprise et à but non lucratif, puis en juin 2027 pour les comptes Education. Le déploiement est progressif ; consultez les indications correspondant à votre compte et demandez à votre administrateur si l'accès est géré. Aide sur la transition des Gems vers les Skills

Un Skill doit décrire une tâche répétable

Google présente les Skills comme des instructions réutilisables entre plusieurs discussions, sélectionnables explicitement ou applicables lorsqu'elles sont pertinentes, et combinables pour des tâches plus complexes. Le guide de création actuel prend en charge un fichier racine SKILL.md avec des ressources de référence compatibles en option et énonce des restrictions concernant les actions externes des scripts téléversés. Il est donc important de distinguer un ensemble d'instructions d'un programme sans restriction autorisé à utiliser des sites web. Créer et gérer des Skills pour Gemini Apps

L'erreur la plus facile consiste à transformer chaque long prompt en Skill. La longueur n'est pas le critère déterminant. Un Skill utile a une fonction reconnaissable, une entrée claire, une norme de sortie et des conditions dans lesquelles il ne doit pas agir. Si ces éléments manquent, la réutilisation automatique risque de répéter une ambiguïté plutôt que de faire gagner du temps.

Imaginons une configuration hypothétique appelée « note de recherche ». Elle ne devrait pas se contenter de dire « sois minutieux ». Elle pourrait demander une question de recherche, une date limite, des liens vers des sources primaires et une distinction entre constats confirmés et interprétation. Elle pourrait interdire d'inventer une source lorsque les preuves manquent. Ces exigences rendent le résultat plus facile à vérifier et la tâche plus facile à reconnaître.

Imaginons maintenant une configuration distincte de « style éditorial ». Elle pourrait demander des paragraphes courts, un langage simple et des titres cohérents. Séparer cette configuration des critères de preuve peut rendre la réutilisation plus flexible. Un utilisateur pourrait appliquer les mêmes exigences de preuve à une enquête technique et à une note d'actualité tout en choisissant des styles rédactionnels différents. C'est là l'intérêt de la composition, à condition que les instructions ne se contredisent pas.

Faites l'inventaire de l'intention avant de copier le texte

Avant de migrer un Gem, notez ce qu'il fait bien. Pour quelles tâches l'utilisez-vous ? Quelles informations fournissez-vous habituellement ? Quelles parties du résultat corrigez-vous systématiquement ? Quels fichiers de référence sont indispensables, et lesquels ont été ajoutés il y a des mois pour une tâche ponctuelle ? Cet inventaire vaut davantage que la conservation d'un prompt dont personne ne comprend la complexité accidentelle.

Séparez les règles durables du contexte temporaire. « Distinguer l'affirmation d'une entreprise d'une mesure indépendante » est une règle de recherche durable. « Notre lancement a lieu jeudi prochain » est un contexte temporaire qui peut devenir faux dès que le calendrier avance. Une instruction réutilisable ne devrait pas transporter silencieusement de vieux faits dans une nouvelle tâche au seul motif qu'ils ont été utiles une fois.

Vérifiez si des informations privées se cachent dans les exemples. Un nom de client réel, une adresse interne ou un plan d'affaires non publié a pu entrer dans le prompt initial à titre d'exemple commode. Cela ne signifie pas qu'il doit figurer dans une configuration réutilisable. Remplacez les détails inutiles par des exemples neutres et protégez les informations sensibles nécessaires au moyen des contrôles d'accès et de compte appropriés.

L'inventaire doit aussi faire ressortir les hypothèses jamais écrites. Peut-être qu'un collègue vérifiait toujours les chiffres définitifs, ou que vous fournissiez systématiquement un document source avant de commencer. Si le nouveau flux rend le Skill disponible dans de nombreuses conversations, ces hypothèses risquent de ne plus tenir. Transformez-les en exigences explicites au lieu d'espérer que le contexte environnant reste identique.

Gardez une copie de référence portable

Liste de contrôle originale de migration. La comparaison est un processus de vérification proposé, pas un résultat de migration de compte rapporté par Google.

Une copie portable fournit un document de référence lorsqu'une interface change. Elle peut contenir le nom, l'objectif, les instructions, la liste des fichiers de référence et quelques exemples de tâches. Utilisez des formats ordinaires lisibles sans dépendre d'un produit. Il ne s'agit pas d'une promesse de compatibilité universelle à l'importation, mais d'un moyen de préserver le sens de la personnalisation lorsque le mécanisme d'importation diffère.

Pour chaque fichier de référence, notez pourquoi il est présent et quand il a été vérifié pour la dernière fois. Un document de politique peut faire autorité dans une organisation et être sans pertinence ailleurs. Un guide de style peut devenir obsolète. Un tableau peut contenir des informations qui ne doivent pas sortir de l'équipe. Le nom du fichier suffit rarement à exprimer ces contraintes.

Conservez la configuration originale pendant l'évaluation de la candidate. Une migration peut préserver le texte tout en modifiant le comportement, car le modèle, les outils ou le contexte de conversation environnants sont différents. Une copie de référence facilite la distinction entre un problème d'instructions et un changement de plateforme. Elle empêche aussi qu'une réécriture précipitée devienne la seule version restante.

Ne confondez pas portabilité et distribution sans restriction. Une configuration peut inclure des ressources de référence sous licence ou des informations privées. Le fait qu'elle tienne dans un fichier texte ne rend pas sa publication ou son envoi à un autre service approprié. Examinez le contenu et la destination avant de partager un Skill avec des collègues ou d'en importer un d'un auteur inconnu.

Un petit modèle est plus facile à vérifier qu'un prompt géant

L'exemple suivant est un modèle de recherche original et volontairement minimal. C'est un contenu à adapter dans un éditeur local, pas une commande à exécuter dans un shell. Il n'affirme pas que Google exige précisément ces titres et doit être vérifié au regard du guide actuel de la plateforme avant importation.

---
name: source-linked-research
description: Rédiger une note de recherche qui distingue les preuves de l'interprétation.
---

# Entrées
- Question de recherche et public visé.
- Date limite et sources approuvées ou périmètre de recherche.

# Méthode
- Privilégier les sources primaires pour les affirmations factuelles sur un produit.
- Distinguer les annonces, les mesures et les analyses personnelles.
- Signaler les preuves manquantes au lieu d'inventer des faits ou des citations.

# Résultat
- Conclusion principale, liens à l'appui et questions non résolues.
- Aucune soumission ou publication externe sans autorisation distincte.

La valeur ne tient pas à la formulation choisie, mais à la visibilité du contrat. Un lecteur peut repérer les entrées, examiner la règle sur les preuves manquantes et constater que publier constitue une action séparée. Un futur éditeur peut modifier une exigence sans devoir démêler une page d'instructions de persona sans rapport.

Gardez des exemples assez modestes pour révéler une défaillance. Pour une recherche liée à des sources, incluez un cas avec des dates contradictoires et un autre où une affirmation ne dispose pas de source primaire. Pour une révision de document, ajoutez un fichier contenant une exigence ambiguë. Un modèle qui ne réussit que sur des entrées simples et complètes ne démontre pas grand-chose sur le travail quotidien.

N'intégrez pas de secrets, de jetons d'authentification ou d'instructions d'outils sans restriction dans un fichier de Skill. Une instruction réutilisable doit décrire la tâche, pas servir de coffre à identifiants. Si une tâche nécessite l'accès à des informations privées, cet accès relève des contrôles de compte et d'autorisation appropriés de la plateforme. La commodité ne doit pas dissimuler des données sensibles dans une configuration.

Combiner des Skills peut aussi combiner les contradictions

La composition est séduisante, car les tâches réelles ont plusieurs dimensions. Un rapport peut nécessiter une norme de recherche, un style maison et une explication adaptée à son public. Mais les instructions peuvent s'opposer : l'une exige une réponse brève, l'autre un audit exhaustif ; l'une encourage des recommandations tranchées, l'autre exige de mettre clairement en évidence les incertitudes non résolues. Un flux utile repère la contradiction plutôt que de produire un compromis arbitraire.

Commencez par deux Skills complémentaires avant d'en ajouter beaucoup d'autres. Vérifiez si la norme de preuve survit à l'instruction de style et si le résultat reste adapté au public. Si le résultat change de façon inattendue, testez chaque Skill séparément. Sinon, une erreur devient difficile à attribuer et les utilisateurs risquent de répondre en ajoutant encore des instructions à une pile grandissante.

L'activation explicite peut être utile pendant l'évaluation. La sélection automatique selon la pertinence est pratique lorsqu'elle fonctionne, mais elle peut rendre moins évidentes les instructions appliquées. Pour une tâche importante, notez quel Skill vous vouliez utiliser et vérifiez si le résultat le respecte. C'est une recommandation de contrôle, pas l'affirmation qu'une interface donnée fournit un historique complet des instructions.

Limitez assez le périmètre pour qu'un Skill ne s'applique pas à des tâches sans rapport. Une règle de « recherche financière » ne devrait pas remodeler silencieusement une conversation créative. Un modèle de service client ne devrait pas transformer une question personnelle en ticket formel. Une bonne personnalisation consiste aussi à savoir quand elle est hors sujet.

Comparez des tâches avant d'abandonner l'ancien flux

Une vérification pratique de migration utilise le même petit ensemble d'entrées avant et après le changement. Incluez un cas ordinaire, une entrée incomplète et un cas limite qui nécessitait auparavant une correction. Comparez le fond, pas seulement la mise en forme. Les réserves nécessaires ont-elles été conservées ? Des détails manquants ont-ils été inventés ? La limite relative aux actions externes a-t-elle été maintenue ?

Pour un flux de recherche, examinez chaque lien essentiel dans un résultat de test. Pour un flux éditorial, vérifiez que le sens voulu subsiste après la réécriture. Pour un passage de relais interne, confirmez que les responsabilités et les questions non résolues ne sont pas transformées en tâches accomplies. Ces vérifications doivent correspondre à la tâche plutôt que de s'en remettre à un score de « qualité » générique unique.

Notez la date, le type de compte et la version de la configuration utilisés pour la comparaison. Cela facilitera les enquêtes ultérieures. Si le résultat se dégrade après une mise à jour, vous pourrez déterminer si l'instruction, les sources ou la plateforme ont changé. Sans point de référence, chaque enquête commence par un souvenir incertain de la manière dont les choses fonctionnaient auparavant.

Pour un usage personnel, aucun grand système d'évaluation n'est nécessaire. Une courte liste de contrôle et quelques exemples enregistrés peuvent suffire à repérer les régressions évidentes. Les équipes dont les flux ont des conséquences importantes auront peut-être besoin d'une révision plus formelle, mais le principe reste le même : une migration est achevée lorsque le comportement visé a été vérifié, pas simplement lorsqu'un fichier a été importé.

La personnalisation exige autant de responsabilité que de commodité

Cette transition annonce un avenir plus vaste où les utilisateurs emportent des façons de travailler réutilisables d'une tâche à l'autre au lieu de repartir d'un prompt vierge à chaque fois. Cela peut être précieux. Cela peut aussi créer une nouvelle forme de logiciel accumulé : des ensembles d'instructions et de références qui influencent des décisions importantes sans ressembler à des applications classiques.

Quelqu'un doit être responsable de cet ensemble. Qui met à jour les fichiers de référence ? Qui réexamine un Skill partagé après une modification de politique ? Qui décide si une instruction importée est appropriée ? Il est facile de remettre ces questions à plus tard quand la personnalisation ressemble à de simples prompts occasionnels. Elles deviennent plus difficiles à ignorer lorsque la même configuration est réutilisée chaque jour par une équipe.

Pour une personne, la responsabilité peut rester modeste : conserver des copies lisibles, supprimer les hypothèses périmées et vérifier les résultats importants. Pour une organisation, elle peut nécessiter des configurations approuvées, des règles d'accès et un processus de révision. Aucune de ces formules ne doit traiter la personnalisation comme une garantie d'exactitude. Un assistant familier peut toujours commettre une erreur inattendue.

Migrez le flux de travail, pas seulement son nom

La préparation la plus utile consiste à préserver la tâche accomplie par votre Gem et à en expliciter les exigences. Gardez une copie de référence, identifiez les fichiers dont il dépend, séparez les règles stables des faits temporaires et testez la version candidate avec des entrées représentatives. Consultez ensuite les informations de déploiement pour votre compte réel au lieu de supposer une échéance mondiale unique.

Les Skills peuvent rendre la personnalisation plus réutilisable et composable. L'avantage viendra de contrats clairs et d'une vérification attentive, pas du seul mot « Skill ». À mesure que les outils d'IA deviennent plus personnels, la configuration précieuse sera celle que vous pouvez comprendre, maintenir et vérifier. Transmettre cette compréhension compte davantage que copier un prompt dans un nouvel écran.

Regrouper vos décisions de migration au même endroit

Pour les lecteurs qui organisent leurs recherches, leurs notes de configuration et leurs décisions de vérification, Telli.sh est un espace facultatif. Créer une note de révision.