Le point de départ n'est pas la liste de tout ce qu'un agent pourrait faire. Cette liste devient vite impressionnante : préparer des rendez-vous, classer des documents, rédiger des contenus, répondre aux clients, mettre à jour des outils ou surveiller des sources.
Elle aide peu à décider.
Quand je cherche un premier usage pour mon propre système IA personnel, je pars d'une friction qui existe déjà dans mon travail. Je regarde ensuite si le contexte est disponible, si le résultat attendu peut être décrit et si une erreur resterait visible et récupérable.
Cette sélection compte davantage que le choix du modèle. Un usage bien borné peut déjà être utile avec peu d'autonomie. Un usage mal défini reste fragile, même avec un agent plus performant.
Un premier cas d'usage IA doit prouver que le système mérite une place dans votre quotidien, pas qu'il peut tout faire.
Un cas d'usage n'est pas une capacité technique
Un agent peut techniquement lire des fichiers, rechercher une information, appeler un outil ou écrire dans un dossier. Ces capacités ne disent pas encore ce qu'il devrait faire pour vous.
Un cas d'usage relie six éléments :
- une situation qui revient ;
- un déclencheur identifiable ;
- des sources autorisées ;
- un résultat attendu ;
- une validation ;
- un comportement prévu en cas d'échec.
« M'aider à gérer mon activité » n'est pas un cas d'usage. La demande ne précise ni les informations à consulter, ni la sortie à produire, ni le moment où l'agent doit s'arrêter.
« À partir d'un lien envoyé dans Discord, préparer une capture dans mon Inbox Obsidian avec le titre, la source et un résumé » est déjà plus exploitable. Le déclencheur est connu. Les outils et la destination sont limités. Le résultat peut être relu. Si la page est inaccessible, l'agent peut laisser la capture en attente au lieu d'inventer son contenu.
La différence entre les deux tient au périmètre, pas au niveau d'intelligence du modèle.
Pourquoi le premier usage doit rester petit
Anthropic recommande de commencer par la solution la plus simple et d'ajouter de la complexité seulement lorsqu'elle améliore le résultat. L'entreprise distingue notamment les workflows, dont le chemin est défini à l'avance, des agents qui choisissent plus dynamiquement leurs étapes et leurs outils.
Cette distinction évite d'utiliser un agent là où une règle ou un enchaînement fixe suffirait. Elle ne répond pas encore à une autre question : parmi tous les problèmes possibles, lequel mérite d'entrer en premier dans votre quotidien ?
C'est la frontière de cet article. Il ne cherche pas à répartir toutes les étapes d'un processus entre règles, IA et humains. Il sert à sélectionner le premier usage autour duquel construire le système. La répartition détaillée vient ensuite.
Pour un solopreneur, le premier usage sert aussi de test d'adoption. Il permet d'observer :
- si l'interface choisie est assez simple pour être utilisée sans y penser ;
- si les bonnes informations sont disponibles au bon endroit ;
- si les permissions sont compréhensibles ;
- si la sortie réduit réellement une friction ;
- si les corrections peuvent améliorer les exécutions suivantes.
Un périmètre trop large mélange ces questions. Si le résultat déçoit, il devient difficile de savoir si le problème vient des sources, du modèle, des consignes, des permissions ou du processus lui-même.
Un petit usage rend l'apprentissage plus lisible. Une fois l'usage retenu, tester l'agent scénario par scénario permet de vérifier qu'il agit dans le périmètre prévu avant l'adoption quotidienne.
Partir d'une friction informationnelle récurrente
Les cas d'usage les plus prometteurs ne commencent pas toujours par une tâche longue. Ils commencent souvent par une reconstruction de contexte répétée.
Vous cherchez les mêmes notes avant chaque rendez-vous. Vous relisez plusieurs documents pour retrouver une décision. Vous capturez des ressources sans les revoir. Vous préparez un livrable à partir d'informations réparties entre des messages, des notes et des fichiers.
Prenez un épisode récent et décrivez-le sans parler d'IA :
- qu'est-ce qui a déclenché le travail ?
- quelles informations avez-vous cherchées ?
- où se trouvaient-elles ?
- quelle sortie avez-vous produite ?
- qu'avez-vous dû vérifier vous-même ?
- que s'est-il passé lorsqu'une information manquait ?
Cette description fait apparaître le travail informationnel réel. Elle évite de concevoir un système autour d'une démonstration séduisante mais étrangère à vos habitudes.
Le meilleur candidat n'est pas nécessairement la tâche qui prend le plus de temps en une seule fois. Une petite friction répétée plusieurs fois par semaine peut fournir un meilleur point de départ, parce qu'elle donne davantage d'occasions d'utiliser, de corriger et d'évaluer le système.
Les sept critères d'un bon premier cas d'usage IA
1. La situation revient assez souvent
Un usage annuel apprend peu sur l'intégration du système au quotidien. Il peut être rentable sur le papier tout en restant oublié entre deux exécutions.
La fréquence crée une boucle courte : demande, résultat, correction, nouvelle utilisation. Elle révèle rapidement si l'agent facilite le travail ou ajoute une étape.
Je privilégie donc un usage qui revient chaque semaine, voire plusieurs fois par semaine, sans en faire une règle universelle. Une tâche moins fréquente peut rester pertinente si son enjeu le justifie et si elle est assez stable pour être testée.
2. Le contexte nécessaire existe déjà
Un agent ne peut pas retrouver une décision qui n'a jamais été enregistrée. Il ne peut pas produire un brief fiable si les informations utiles restent dispersées dans des espaces auxquels il n'a pas accès.
Avant de parler d'automatisation, listez les sources nécessaires. Pour chacune, vérifiez :
- qu'elle existe ;
- qu'elle est lisible par le système ;
- qu'elle fait autorité pour l'information concernée ;
- que son accès est légitime ;
- qu'elle peut être distinguée d'une ancienne version ou d'une hypothèse.
Si ce travail révèle une base documentaire confuse, le premier chantier peut être la clarification du contexte plutôt que l'ajout d'un agent.
3. La sortie attendue peut être décrite
« Faire une bonne synthèse » laisse beaucoup de place à l'interprétation. « Produire un brief avec le contexte, les décisions actuelles, les questions ouvertes, les sources utilisées et les informations manquantes » donne une sortie que l'on peut examiner.
Une sortie bornée n'a pas besoin d'être rigide. Elle doit permettre de répondre à trois questions :
- le résultat contient-il les éléments attendus ?
- peut-on retrouver les sources utilisées ?
- l'absence d'information reste-t-elle visible ?
Plus ces réponses sont simples, plus le cas se prête à une première mise en place.
4. La vérification coûte moins cher que la production
Un agent n'apporte pas grand-chose si contrôler son travail demande autant d'effort que tout refaire.
Le premier usage doit produire un résultat que vous savez relire. Vous connaissez le dossier, vous pouvez ouvrir les sources et vous savez reconnaître une omission importante.
Cette condition écarte les domaines où vous ne disposez pas de l'expertise nécessaire pour juger la sortie. Elle écarte aussi les résultats trop diffus, sans critère d'acceptation ni provenance.
5. Une erreur reste visible et récupérable
Une mauvaise capture dans une Inbox peut être corrigée ou supprimée. Un message envoyé au mauvais client est plus difficile à reprendre. Une publication, une dépense ou la suppression d'un fichier important augmente encore le coût de l'erreur.
Pour un premier usage, je préfère que l'agent prépare plutôt qu'il n'engage :
- préparer un brief plutôt qu'inviter automatiquement des participants ;
- créer un brouillon plutôt que l'envoyer ;
- proposer une modification plutôt que réécrire silencieusement une note de référence ;
- classer dans un espace de capture plutôt que déplacer définitivement un document.
La validation humaine reste proche de la sortie. L'autonomie peut évoluer plus tard si les tests et l'historique le justifient.
6. Le comportement d'échec est prévu
Un système fiable n'est pas celui qui répond dans tous les cas. Il sait laisser une information absente, signaler une contradiction et demander de l'aide lorsque l'action sort de son périmètre.
Avant de retenir un cas d'usage, décrivez au moins ces situations :
- une source est inaccessible ;
- deux documents se contredisent ;
- un champ obligatoire manque ;
- la sortie ne respecte pas le format attendu ;
- l'action demandée dépasse les permissions.
La réponse acceptable peut être simple : arrêter le traitement, conserver les éléments déjà obtenus et présenter le blocage à la personne responsable.
7. L'usage donne envie de revenir au système
Ce dernier critère est moins technique, mais il décide souvent de l'adoption.
Le premier usage doit s'insérer dans une interface déjà naturelle et produire une sortie que vous utilisez. Une architecture propre qui exige d'ouvrir un outil oublié ou de suivre une procédure disproportionnée restera inactive.
Dans mon système, Discord sert d'interface quotidienne. Obsidian contient la mémoire de travail. L'agent relie les deux dans les limites prévues. Je n'ai pas besoin de déplacer toute ma connaissance dans la messagerie pour utiliser le système depuis mon téléphone ou mon ordinateur.
Le bon usage crée un retour concret : une ressource capturée, un contexte retrouvé, un brief prêt à relire ou un brouillon fondé sur des notes existantes. Ce retour donne une raison de recommencer.
Exemple réel : capturer une ressource sans remplir automatiquement la mémoire
L'un de mes usages consiste à envoyer une ressource à mon agent depuis Discord.
L'agent ouvre la source, prépare une synthèse et crée une note dans mon Inbox Obsidian avec l'URL et un statut de capture. Cette étape réduit la friction entre la découverte d'une ressource et son enregistrement dans un espace que je possède.
Le périmètre s'arrête volontairement là.
L'agent ne décide pas que la ressource est fiable, durable ou suffisamment importante pour rejoindre ma mémoire de référence. Je fais ce tri pendant ma revue. Je peux corriger la note, la relier à un projet, la transformer en idée ou la supprimer.
Ce cas fonctionne comme premier usage parce que :
- le déclencheur est un lien envoyé volontairement ;
- les sources et la destination sont connues ;
- la sortie suit une structure lisible ;
- une erreur reste facile à repérer et à corriger ;
- aucune publication ni décision externe n'est déclenchée ;
- chaque utilisation améliore la compréhension de ce que je souhaite conserver.
Il montre aussi une limite importante : accélérer la capture ne suffit pas à construire une bonne mémoire. La sélection reste un travail distinct.
Les mauvais premiers candidats
Certains usages peuvent devenir utiles plus tard sans être de bons points de départ.
Un agent chargé de « gérer l'activité »
Le périmètre ne permet pas de savoir quelles sources sont autorisées, quelles décisions restent humaines ni comment évaluer le résultat.
Une action externe difficile à annuler
Envoyer des messages, publier, supprimer ou engager une dépense demande des permissions, des tests et une validation adaptés au risque. Commencer par la préparation de l'action permet d'apprendre avec moins de conséquences.
Un processus qui change à chaque exécution
Si vous ne savez pas expliquer comment le travail se déroule aujourd'hui, l'agent héritera de cette instabilité. Il vaut mieux clarifier le processus ou conserver un traitement humain.
Une tâche sans source de vérité
Une synthèse peut être bien écrite tout en reposant sur une version obsolète. Le système doit savoir où vérifier l'état actuel et différencier un fait, une décision et une hypothèse.
Un usage choisi uniquement parce que la démonstration impressionne
Une démonstration mesure ce que le système peut produire une fois. Elle ne prouve ni son adoption, ni sa fiabilité dans votre contexte, ni sa valeur après plusieurs semaines.
Comment départager deux cas d'usage
Il n'est pas nécessaire de construire une note complexe ou de fabriquer un score précis. Comparez les candidats avec quelques questions :
- Combien de fois la situation s'est-elle produite récemment ?
- Les sources sont-elles identifiées et accessibles ?
- La sortie attendue tient-elle dans un format connu ?
- Savez-vous vérifier le résultat rapidement ?
- Une erreur est-elle visible et réversible ?
- Une action externe peut-elle rester sous validation ?
- Utiliserez-vous réellement cette sortie ?
Si un candidat dépend d'informations introuvables, d'un résultat difficile à juger ou d'une autonomie élevée, réduisez son périmètre.
« Préparer et envoyer une réponse client » peut devenir « réunir le contexte et préparer un brouillon cité ». « Organiser toute ma base de connaissances » peut devenir « créer une capture structurée dans l'Inbox ». « Préparer mes rendez-vous » peut commencer par « réunir les décisions actuelles et les questions ouvertes d'un seul projet ».
La réduction du périmètre n'est pas un renoncement. Elle rend le premier test interprétable.
Tester l'usage avant de l'étendre
Une exécution réussie ne suffit pas pour conclure.
Testez le cas avec des exemples ordinaires, des informations manquantes, une source inaccessible, une demande hors périmètre et une sortie invalide. Vérifiez aussi que l'agent refuse ou soumet à validation ce qu'il ne doit pas faire seul.
Après plusieurs utilisations réelles, regardez ce qui s'est passé :
- avez-vous utilisé la sortie ?
- quelles corrections reviennent ?
- quelles sources manquent souvent ?
- à quel moment l'agent demande-t-il trop ou pas assez de validation ?
- savez-vous reprendre manuellement lorsqu'il échoue ?
Cette observation décide de la suite. Vous pouvez stabiliser l'usage, réduire encore son périmètre ou ajouter une extension précise. Vous pouvez aussi l'abandonner si le retour ne justifie pas sa place dans votre système.
Ce choix n'est pas seulement théorique. Lors de ma première mise en place payante, la préparation de plusieurs usages a augmenté le nombre de comportements à expliquer et à tester. Je détaille cette correction dans mon retour sur la mise en place d'un agent IA.
L'article sur l'automatisation des processus métier permet ensuite de répartir les étapes entre règle déterministe, automatisation classique, modèle génératif, agent borné et validation humaine.
Commencer par un retour utile
Un système IA personnel devient durable lorsqu'il relie un agent à une mémoire, des permissions, une interface quotidienne et une capacité de reprise. Son premier usage doit rendre cet ensemble visible dans une situation simple.
Le meilleur candidat n'est pas celui qui mobilise le plus d'outils. C'est celui qui produit assez souvent une sortie utile, dans des limites que vous comprenez.
Choisissez une friction informationnelle récente. Définissez les sources, la sortie, la validation et l'échec. Puis laissez le système gagner progressivement le droit d'en faire davantage.