Context Engineering pour Agents IA: Instructions, Skills, Commands et Custom Agents

Et bonjour à toutes et à tous. Bonjour

Tug.

Bonjour Arthur, bonjour à tous.

Hop. Alors comme d'habitude, on va attendre 2 3 minutes que tout le monde ait le temps de d'arriver. Dans tous les cas, pour rappel, il y a un RIPT qui va être disponible sur YouTube et qui sera

donc partagé dans tous les cas sur LinkedIn et on partagera le lien YouTube. Normalement, si vous êtes

YouTube. Normalement, si vous êtes inscrit dans tous les cas sur Livestorm, vous allez recevoir un mail avec le Rip à la fin d'événement directement. Donc

ça va aller très vite. Vous pourrez

partager du coup sans problème.

Hop.

Et bonjour tout le monde.

Tac.

Alors pour les questions, on va essayer d'en prendre en live dans le chat pendant la présentation et l'échange et hésitez pas à utiliser l'onglet question

qui est dédié à ça en bas à droite si vous avez des questions qu'on pourra apprendre aussi à la fin ou qu'on prendra justement au moment où on aura un petit peu de temps. On va essayer de

pas trop trop parler mais vu de sujet, il y aura peut-être beaucoup de choses à dire.

Bonjour tout le monde. On va commencer à à 17h05 dans 10 minutes.

Tuug pas trop de déplacement ces derniers temps.

Ah non, ça va. [rires]

À la maison content.

Ça me laisse du temps justement pour tester toutes les nouvelles fonctionnalités qu'on a un peu partout.

Euh donc copilote et sur globalement mais également discuter avec toi des nouvelles fonctionnalités de Pacm et de du context engineering globalement.

Les voyages à suivre à la maison. C'est

bien.

Ouais, c'est clair. Est-ce que tu arrives à suivre toutes les nouveautés au fait qui sortent tu vois côté copilote ou autre justement ou est-ce que même toi tu arrives à être dépassé des fois par tout ce qui sort chaque

semaine ? Je suis dépassé en fait

semaine ? Je suis dépassé en fait justement, je pense que ben dans l'audience, on doit tous être un peu près dans cette situation. C'est-à-dire

qu'avec là, je parle vraiment que d'ilia pour les développeurs et tout ce qui tourne autour, c'est que ça va très très très vite et en plus moi bon ma vie est relativement simple parce que je dois me

concentrer sur un produit qui est guitup et guitup copilot, mais les gens qui font de la veille ont en plus tous les autres produits concurrents et c'est très très dur. Donc c'est parti des soirées, des sessions comme on fait

aujourd'hui. Et entre vous aussi, c'est

aujourd'hui. Et entre vous aussi, c'est très important de partager euh au sein de l'équipe Gitub. On est je sais pas combien on est autour du de la partie technique, les solutions d'ingénier, les

copilot spécialistes, les club solution architectes, les customers success architect et on partage énormément en interne les trucs et astuces, les nouvelles fonctionnalités qu'on a raté

et ça fait partie du travail quoi de de faire de la veille et partager.

Et il faut accepter d'être en retard.

Exactement. Super. Bah c'est une bonne une bonne intro. Euh bonjour à toutes et à tous. Encore une fois, on va démarrer.

à tous. Encore une fois, on va démarrer.

Donc comme je rappé, il y a un replay qui sera disponible par la suite et on va essayer de partager aussi quelques liens directement dans le chat mais si vous avez besoin de plus d'information

hésitez pas à nous retrouver. Comment

les gens peuvent te contacter d'ailleurs Tug ? Est-ce que c'est sur LinkedIn ou

Tug ? Est-ce que c'est sur LinkedIn ou Link ? Ça va être le plus simple.

Link ? Ça va être le plus simple.

Twitter.

Ouais.

Euh et si je réponds pas, faut relancer.

[rires] C'est ça. Super. Ben écoute, je te

C'est ça. Super. Ben écoute, je te laisse te présenter. Ravi que tu sois parmi nous aujourd'hui parce que voilà, là c'est un vrai sujet sujet très chaud du moment. Tout le monde nous pose des

du moment. Tout le monde nous pose des questions et ça fait du bien d'avoir un vrai expert qui développe justement exactement dans ce sujet-là pour pouvoir nous en parler. Donc je te laisse te présenter un petit peu si tu veux. Oui.

Donc je suis Tuc Dual Grade, donc les gens m'appellent Tub. Tuc Dual, c'est un prénom Breton. Je suis depuis peu depuis

prénom Breton. Je suis depuis peu depuis le début de l'année, on va dire copilote spécialiste ou AI spécialiste chez GitHub. Mais mon métier pendant les cinq

GitHub. Mais mon métier pendant les cinq dernières années GitHub, c'était Solution Engineer où c'était toute la plateforme GitHub. Et là, je vais me

plateforme GitHub. Et là, je vais me concentrer plus maintenant sur la partie IA. Et

IA. Et ce qui est intéressant, c'est que j'ai commencé à utiliser GitOP Copilot en septembre 2021. Je sais pas si vous vous

septembre 2021. Je sais pas si vous vous souvenez, c'est sorti en juin 2021 et euh chat GPT novembre 2022 et j'ai suivi, subi, utiliser toutes les

évolutions. Par contre, il s'est passé

évolutions. Par contre, il s'est passé quelque chose justement il y a il y a on va dire il y a un an ou deux qui est vraiment autour du contexte engriering, ce dont on veut aborder, ce ce dont on veut parler aujourd'hui. Et Arthur, ben

je t'ai je t'ai rencontré à Devox il y a de 2 ans. C'est ça.

C'est ça. Ouais.

Le stand était en face de celui de Vit Copilot. On a discuté, on a on a trouvé

Copilot. On a discuté, on a on a trouvé des pas mal de de passions communes, en tout cas sur le développement et euh c'est comme ça qu'on a été amené à discuter souvent ensemble et euh parler

ensemble comme on fait ce soir.

Yes. Ben merci encore une fois d'être là. Effectivement, on s'est rencontré il

là. Effectivement, on s'est rencontré il y a 2 ans et puis les sujets sont tellement croisés que évidemment c'est normal qu'on qu'on en discute. Moi de

mon côté donc je suis Arthurman, je suis le cofondateur et CPO de Pacmind. On

aura l'occasion un petit peu de parler de la solution, mais c'est une solution open source qui permet justement de aux équipes de faire du contexte engineering à déchet de manière simple et avec tout ce qui va tourner autour de la gouvernance et cetera, de la

centralisation. Donc on en parlera

centralisation. Donc on en parlera plutôt à la fin de la discussion justement parce que c'est euh c'est un peu l'étape d'après de ce qui arrive quand on a commencé à avoir des standards, des skiss et cetera. c'est

comment est-ce qu'on les maintient à jour, comment est-ce qu'on gouverne un petit peu tout ça. Et du coup, comme je disais, hésitez pas à poser des questions euh dans le chat en live qui sont en rapport avec le sujet évidemment

et euh comme ça on pourra y répondre un petit peu pendant la présentation. Vous

vexez pas si on répond pas à toutes les questions, on essaiera d'en garder pour la fin, de garder un petit peu de temps.

Hop, je vais partager mon écran.

Tac.

Alors, j'avais pas vraiment prévu à la base de présenter des slides, mais j'aime bien illustrer quand même, voilà, avec des trucs que j'ai dessiner moi-même qui sont pas du tout générés par

juste pour faire un petit point sur avant de parler de contexte adering, pourquoi est-ce qu'on en arrive là aujourd'hui ? Aujourd'hui, en fait, on a

aujourd'hui ? Aujourd'hui, en fait, on a le lia qui est disponible un petit peu partout dans les équipes de dev et certaines personnes au début justement 2021 2022 se sont dit ça va être magique, on va résoudre tous les

problèmes avec ça puis avec un petit prom je vais avoir une super application. Ça marche bien pour des tod

application. Ça marche bien pour des tod list ou des exemples simples, mais dès qu'on arrive sur des systèmes complexes ou dans des entreprises, ben évidemment, on se rend compte que ça marche pas très bien. Ça nous crée des châteaux de

bien. Ça nous crée des châteaux de cartes qui sont à deux doigts de se casser la gueule quand on commence à enchaîner 5 10 commit avec de l'IA. Et

ça c'est un ressenti qu'on a pu avoir personnellement quand on travaille sur les projets. En fait, il y a des études

les projets. En fait, il y a des études qui sont sorties petit à petit à petit plein d'études mais notamment il y a l'études d'Ora. Alors, j'ai vu qu'il y

l'études d'Ora. Alors, j'ai vu qu'il y avait Geoffrey Graveau dans en assistance qui connaît très bien. Euh

une étude d'Ora justement de Google a sorti euh pas mal d'information intéressante sur les entreprises qui utilisent de DIIA. Et ce qu'on voit c'est que individuellement on a l'impression d'aller plus vite, on va

plus vite, on va produire plus de codes, c'est très facile de produire beaucoup de code. Par contre, on a une perte de

de code. Par contre, on a une perte de stabilité sur les logiciels. Ça veut

dire que plus on va utiliser d'IA, plus peut-être qu'on va avoir de bugs, on va avoir des problèmes de maintenance et cetera. Donc évidemment ça peut poser

cetera. Donc évidemment ça peut poser problème. D'autant plus que dans l'étude

problème. D'autant plus que dans l'étude de Dora là de 2025 ce qui remarque c'est que 30 % des gens n'ont pas confiance dans le code généré par LIA ou très peu confiance. Et quand on écoute le

confiance. Et quand on écoute le discours des gens de Microsoft ou de GitHub justement qui disent "Ben l'avenir en 2026 c'est des équipes avec un mélange humain et agent."

Ça fait peur de se dire que 30 % des gens vont pas avoir confiance en ce que vont produire les agents. Ça passe pas à d'échelle comme ça. On va dire on peut pas travailler dans une équipe où on n pas confiance dans le to qui est

général. Donc ce qui donne en fait

général. Donc ce qui donne en fait aujourd'hui des entreprises qui ont des gains qui sont assez limités quand on se met en quand on met en place de DI justement on a des gains qui vont

peut-être aussi entre les - 15 + 15 % et cetera. Et en fait quand on regarde un

cetera. Et en fait quand on regarde un peu dans le détail, on a l'impression que on a des gains qui sont très limités. Mais si on regarde des études

limités. Mais si on regarde des études qui viennent de DX par exemple, DX qui est un peu justement comme Dora qui fait des études sur l'impact en terme de productivité, de qualité et cetera du code quand on utilise de l'IA, ça c'est

un des graphes qui sont sortis sur l'indicateur qui s'appelle change failure rate. Il y a les mêmes graphes

failure rate. Il y a les mêmes graphes sur la productivité, sur la maintenance du code et cetera. En fait, ça ressemble à ça. Donc chaque barre que vous voyez

à ça. Donc chaque barre que vous voyez ici, ça correspond à une entreprise et en fait au sein même d'une barre, on pourrait faire équipe par équipe dans une entreprise, on aurait le même graphe. C'est très très hétérogène.

graphe. C'est très très hétérogène.

C'était déjà hétérogène avant l'arrivée de l'IA, mais maintenant que l'IA est arrivé, c'est un amplificateur et on voit encore plus les différences entre les entreprises et les équipes. Ce qui

fait vraiment la différence, c'est des équipes qui arrivent justement à transmettre leurs connaissances et à transmettre des bonnes pratiques à leurs agents donc évidemment on est en on est avantagé si on a déjà une bonne

architecture, si on a déjà des bonnes pratiques de base avant de mettre en place des outils comme copilote. Mais

même une fois qu'on a ça, on va mieux pouvoir s'en servir si on commence à lui transmettre tout ça. Et tout ça, ben ça s'appelle du context engineering. En

gros, c'est comment est-ce que je peux transmettre bon contexte à mon ag à mon agenda pour qu'il puisse effectuer une tâche en autonomie sans que j'ai passer 5 jours à retravailler bah tout ce qui marche pas et cetera. Et d'ailleurs, il

y a une des phrases justement de du rapport des Vox qui dit que quand les développeurs apprennent à donner à leurs agents IA justement des bonnes instruction et du contexte qui est efficace, ils ont 30 % de merge request

accepté en plus, ce qui est quand même un impact aussi intéressant.

Et sur ce, effectivement, je vais te laisser la parole TUC parce que maintenant ce qui est intéressant c'est de comprendre comment ça marche concrètement et sur des cas concrets justement, bah à quoi ça ressemble sur des projets de pouvoir communiquer avec

son lien. comment est-ce que tu fais ?

son lien. comment est-ce que tu fais ?

En fait, déjà le point qui est important hein, ce qui ce qui est intéressant dans l'histoire que tu lui as raconté ou dans les retours et et c'est une discussion qu'on a depuis le début euh même depuis le tout début tout début. Alors moi je

vais parler de copilote he beaucoup où on avait les instruction simplement la compétion puis après le chat c'est oh j'ai pas confiance en guitubilot le modèle je sait pas comment je code et

comprend pas mon métier tout ça vous pouvez exactement dire la même chose lorsque vous avez un nouvel employé dans votre équipe si demain je rejoins votre équipe al vous voulez pas de moi dans

l'équipe mais si demain je rejoins votre équipe vous ne connaissez pas mon niveau d'ailleurs ça c'est pas très grave mais comment je pouvez connaître toutes vos votre base de connaissance, votre

métier, les règles que vous appliquez, les frameors que vous utilisez.

Prenez ça juste dans votre dans la mémoire, dans votre mémoire et vous allez vous apercevoir que la façon dont vous travaillez comme ça, c'est relativement simple en fait. c'est je

vais euh vous allez avoir de la documentation quelque part, vous allez partager avec euh du contenu à droite à gauche.

Bah l'idée du contexte engineering, c'est d'essayer de faire tout ça, de l'automatiser, de le de l'organiser pour que le développeur qui utilise de l'IA, ça soit pas le développeur qui fasse le

travail, ça soit l'IA qui va aller chercher ces informations qu'on lui aura euh partagé et va les suivre. Et ce que j'aime dire avec un sourire, alors quand j'ai un sourire, ça veut dire que je vais dire une bêtise. C'est à la

différence de l'humain. C'est-à-dire que

si le jeudi soir vous avez fait la fête, vous allez probablement moins bien coder le vendredi matin que le mercredi matin où vous ou le mardi matin où vous êtes frais. Même si vous connaissez les

frais. Même si vous connaissez les instructions que vous devez suivre, si vous connaissez les pratiques dans la réalité vous êtes fatigué, l'agent si vous utilisez le même contexte engineering avec le même modèle devrait

réagir de la même façon. Et une fois qu'on a compris ça et qu'on l'a testé, on a de plus en plus confiance dans l'IA. Ce qui a ce qui fait que

l'IA. Ce qui a ce qui fait que on arrive à ce 30 % dont tu parlais. Et

ce qui est intéressant aujourd'hui, si on prend l'exemple de GitHub sur le source code de GitHub qui est un depuis 2008 2 million et demi de commit. Alors

je sais pas combien on est de développeurs à travailler sur le le gros monolite historique de en Ruby Rail et cetera.

Il y a 1/3 entre 20 et 30 % des pull request aujourd'hui qui sont 100 % faites par l'I, c'est-à-dire qu'elles sont déléguées. Je parle pas de ce que

sont déléguées. Je parle pas de ce que fait le développeur dans l'IA, je par dans le son dans son VS ou dans la CLI, c'est juste vas-y boss, fais-moi cette tâche, rajoute-moi un future flag,

reconfigure-moi, rajoute-moi des tests, fixe ça et c'est complètement délégalia, ça travaille. Comment ça peut travailler

ça travaille. Comment ça peut travailler ? Parce que ça a suffisamment

? Parce que ça a suffisamment d'information. Il existe en fait selon

d'information. Il existe en fait selon les outils utilisés certaines façons d'organiser le travail et là moi je vais vous partager la façon dont on travaille sur Gitup Copilot. Alors je vais

partager mon écran.

Normalement, vous devriez voir arriver la documentation de VS Code.

Alors, j'ai commencé par VS Code, mais il va avoir le même comportement dans les IDE qui sont euh dans dans les IDE supportés par Gitup

Copilot, dans la ligne de commande de Gitup Copilot, sur le coding agent, c'est sur la partie qui tourne dans le cloud, mais également dans les autres outils d'Il pour les développeurs, les cloud code et cetera vont supporter le

même genre de chose. On va pas nécessairement avoir le fichier instruction, ça va s'appeler uncloud.mnd. Ne soyez pas surpris si moi

uncloud.mnd. Ne soyez pas surpris si moi je prends cette approche, d'accord ? Ça

va être le même principe. Il faut voir ça comme couche. Il y a différentes couches. On veut pouvoir dans un premier

couches. On veut pouvoir dans un premier temps avoir des codings standard qui sont tout le temps tout le temps appliqués. On a besoin de quelque chose

appliqués. On a besoin de quelque chose qui va s'appliquer tout le temps. Par

exemple, quand on va avoir de l'accessibilité ou de la sécurité, indépendamment de si je fais du Java, du Python, du Terraform ou de l'ancible, je veux respecter les mêmes règles pour la

sécurité. Si je fais du front en HTML

sécurité. Si je fais du front en HTML pur, en React, en je ne sais quoi, je veux que l'accessibilité soit commune.

Donc tout ça, ce sont des instructions qu'on va faire soit de façon générique sur tout le projet ou un peu spécialisé sur un ensemble de fichiers et de sous-ficiers. C'est ce qu'on va appeler

sous-ficiers. C'est ce qu'on va appeler les instructions. Là, je vais commencer

les instructions. Là, je vais commencer par ça et je vais vous montrer un projet sur lequel moi je travaille. En fait,

c'est mon projet euh quand je travaille, j'ai un projet qui lit deux de mes passions, le code et la planche à voile.

Donc, c'est un site un peu le strava de la planche à voile qui où j'ai un catalogue là pour me permettre. Tout ça,

je l'ai fait en en XJS avec Chat CN.

Alors, ce qui est intéressant, c'est que je déteste le front. Si je n'avais pas eu Gitop Copilot, je serais resté sur mon vieux site en en Bootstrap et

j'aurais pas touché. Grâce à l'IA, je me suis permis d'apprendre des nouvelles des nouveaux langages et des choses comme ça. Quand je vais voir mon projet,

comme ça. Quand je vais voir mon projet, je vais vous montrer un petit peu le projet. Hop, je switch en différentes

projet. Hop, je switch en différentes partes. Donc ça c'est le backround, ça

partes. Donc ça c'est le backround, ça c'est le frontal. Si vous regardez dans GitHub, j'ai plein de choses. Dans le

fichier GitHub, j'ai des agents, j'ai des instructions, j'ai des promptes. La

première chose que j'ai, c'est un copilot instruction. Ce fichierlél est

copilot instruction. Ce fichierlél est le fichier global qui va s'appliquer tout le temps quand je vais poser des questions. Euh donc là, si je passe en

questions. Euh donc là, si je passe en mode agent classique, quelles sont les langues supportées

par mon appli et je vais prendre un modèle hop euh gratuit, pas gratuit mais qui consomme pas dans mes premiè request parce que c'est simple. Dans ce cas-là,

le le l'agent guit va regarder quels sont les outils à utiliser, mettre du contexte, rajouter dans le contexte un ensemble de fichiers et vous voyez, il a rajouté systématiquement en premier mon

copilot instruction pour comprendre quelle est la règle. Ce fichier là dans le contexte de Gitup Copilot, c'est le premier à faire. La façon dont vous le faites, vous faites comme ça. C'est très

simple. Je vais aller sur un projet où il n'existe pas. Je vais aller sur un projet là, j'ai migré une application DNET, une application Java vers DNET. Si

je commence ici, je vais dans mon chat, je peux demander à Gitup Copilot, je vais zoomer un petit peu ici. Je vais

lui faire init.

Hop, vous faites ça. Init. Soit vous

travaillez comme ça. Si vous êtes fan de la CLI, si vous aimez travailler plutôt en terminal ou sur un autre IDE, bah vous démarrez copilote et copilote va

vous dire regardez, il n'y a pas d'instruction, je vous invite à travailler avec le slash init pour créer ce fichier. Vous choisissez le c'est

ce fichier. Vous choisissez le c'est vous qui choisissez.

Et là, on va voir ce qui se passe. Je

tape init. Alors là, je le fais dans le chat de VS Code parce que ça me permet de vous montrer le prompt que nous on a créé pour vous. En fait,

le promte qu'on a créé pour vous, hop, je voulais l'ouvrir. Voilà, il est là.

Je suis je vais créer une skill qui est de type je vais utiliser des choses en interne pour faire ça. Je vais regarder le fichier. Je vais s'il y a déjà un

le fichier. Je vais s'il y a déjà un agent MD, je vais le mettre à jour. Donc

en fait, vous lui dites simplement ce que vous voulez et là, il va créer un fichier pour moi qui va être le premier point qui va s'appliquer systématiquement dès que je travaille.

Ensuite, je vous parlais d'accessibilité, de sécurité. Un des

défis, c'est comment on fait tous ces fichiers. Alors, si vous commencez

fichiers. Alors, si vous commencez systématiquement tout seul dans votre coin, vous êtes perdu.

UP copilot, les écosystèmes des aut, les choses comme Pacmine et Arthur en parlera plus tard comment Pacmine va vous aider à faire ça. On a maintenant des repository

euh vont on a des repository qui vont appliquer certaines règles.

Donc ce qui va se passer c'est que chez Gitter, on a un ripo qui s'appelle Awesome copilot, je vais le mettre dans le chat qui est l'endroit où faut chercher en premier. Alors ça c'est un projet open source dans lequel vous allez pouvoir travailler. Et si vous

voulez travailler dans mon cas vous voyez ici j'ai un fichier DNET clinique, j'ai quasiment pas de fichier copilot ici vous voyez, j'ai quasiment rien.

Donc ce que j'aimerais c'est rajouter un spécialiste du code pour l'accessibilité et pour la sécurité. Je vais aller chercher dans mes instructions ici.

Alors il y a plein de façons de le rajouter. Moi, je vais le prendre par le

rajouter. Moi, je vais le prendre par le biais de de cette partie là. Donc

instruction, je veux quelque chose de global et je vais aller chercher la partie ASP pour la partie sécurité. Je

vais faire installer. J'aurais pu le faire de Donc là, il va me rajouter le fichier dans mon projet. Où est-ce que je veux le mettre ? Et vous voyez là, il m'a mis un fichier dans mon projet qui va systématiquement

regarder ses règles. Et ça, vous pouvez le modifier exactement comme je vous le disais. Si demain je rentre dans votre

disais. Si demain je rentre dans votre équipe, s'il y a une règle particulière sur la sécurité, vous allez faire cette partie.

Donc il y a plein de choses qui vont travailler cette façonlà. Euh toutes les discussions sur les performances et sur est-ce que un agent point MD rajoute par rapport à l'esquive, par rapport à des instructions, faut tester ça au cas par

cas sur vos projets et en plus ça va varier d'un modèle à un autre, ça va varier d'un outil à un autre. Euh donc

vous allez tester et vous allez l'appliquer mais généralement de toute façon sans contexte surtout dans du métier. C'estàd que faire du V coding et

métier. C'estàd que faire du V coding et créer de nouvelles applications, c'est très simple.

Par contre, faire du brandfil, ajouter votre application, comprendre si vous avez un code Legacy, al moi je viens du monde Java, donc vous avez des différents frameors que vous avez utilisé dans le temps, vous avez des

façons différentes de coder, il est important de créer ces fichiers là. Donc

là, moi j'ai rajouté ici par éc par exemple security et il va s'appliquer systématiquement dès que je vais parler.

Et vous voyez qu'en parallèle de ça, il est toujours en train de créer mon mon prompt mon copilot instruction qui va s'appliquer. Donc ça c'est une question

s'appliquer. Donc ça c'est une question d'ailleurs.

Pardon ?

Ouais, il y a une question justement dans le chat. C'est vrai qu'il y a eu des articles récents. Alors le j'avais un avis effectivement sur le skids vs agent MD, on pourra pas en parler après.

Les deux sont très utiles mais il faut les utiliser comme il faut. Mais il y avait une autre question effectivement, il y a des articles qui sont sortis en disant que les agent MD générés par le slash init de copilote ou en gros les

trucs générés parien un peu généré qui paraphrasent ton code de ton projet ont pas forcément un impact positif parce qu'ils vont te faire consommer plus de tokens pour un résultat moyen. Mais en

fait ça rejoint exactement ce qu'on dit et ce que tu racontes qui est c'est bien à la limite d'avoir un init de base, tu vois, c'est plus pour moi un exemple ou un truc intéressant pour le projet mais il faut surtout pas s'arrêter là. C'est

pour ça que cette étude dit que c'est pas bon. En fait, ce qu'il faut lire

pas bon. En fait, ce qu'il faut lire dans l'étude, c'est créer des choses spécifiques à votre contexte que les agents peuvent pas trop découvrir justement sur c'est quoi vos pratiques de sécurité, c'est quoi la sete que vous visez, c'est quoi les contraintes

métiers que vous avez et cetera. Donc

ouais, cet article ce que j'ai bien aimé, c'est que justement il est en train de dire ça peut pas être automatique, vous avez pas juste amélioré votre agent comme ça. C'est

important d'avoir des trucs spécifiques.

En fait, c'est vraiment faut le prendre ça comme un bootstrap et après vous allez travailler dessus parce que de toute façon, si on regarde le prompt, le prompt il va se concentrer sur certaines tâches, une architecture globale,

comment c'est buildé, comment c'est quelle est la convention et ça c'est par rapport à du code existant. Donc ça va être assez basique et ça peut même être compliqué. C'est faut oui en fait

compliqué. C'est faut oui en fait Frédéric c'est faut le voir un peu comme un exemple où comme Damien faut le voir comme un exemple point en fait un point de départ si vous regardez après moi mon

fichier dans mon projet front il est tout petit et j'ai j'ai référencé deux choses j'ai référencé le le fonctionnel de mon application dans un autre document et l'architecture dans un autre

document pour donner cette partie-là que je fais vivre au fil de l'eau. Si votre

fichier principal vous ne l'avez pas modifié depuis le début et que ça fait 6 mois vous bosez sur le projet, c'est votre instruction. MD copilote

votre instruction. MD copilote instruction cloud.md, agent.md MD à la

instruction cloud.md, agent.md MD à la racine, vous avez probablement fait quelque chose qui va de la même façon lorsqu'il y a des outils qui vous permettent de faire de du de la du

compact sur les sur les agents et des choses comme ça, faites attention parce que l'importance que vous donnez au fichier n'est pas nécessairement la la bonne.

qui donc justement la question je la question qu'il va avoir c'est qu'ensuite vous voyez ici moi j'ai créé un instruction pour l'accessibilité un instruction pour le background qui va

s'appliquer pour les tes types strip que vous allez créer à chaque fois là il va avoir des différentes des différences entre les agents. MD les copilot instruction les cloud.md et cetera.

Gitub historiquement, on a un coplot instruction qui est global qui est ici et ensuite on a un répertoire instruction qui est spécifique par rapport à des chemin. L'agent pointmd,

il peut être mis ici et remplacer le copilot instruction. Ça ça va

copilot instruction. Ça ça va fonctionner de la même façon. Mais

aujourd'hui, toutes les tous les clients Gitup Copilot ne supportent pas supportent le agent. MD, ça c'est sûr, mais le Nestti d'agent, c'est-à-dire pouvoir être mis à tous les répertoires.

Donc moi, je suis encore resté au copilot instruction parce que je travaille avec copilot 99 % du temps.

Donc ça me convient. Si vous avez vraiment besoin de partager, bah là ça peut valoir le coût de créer des agents pointm au lieu des copilot instruction.

Et vous voyez ici he j'ai bien les instructions d'accessibilité, de sécurité qui vont me guider.

L'autre partie toujours dans ce système là, c'est que ça c'est appliqué systématiquement par rapport aux demandes que vous faites. Donc quand je vais faire des choses autour des du

markdown et cetera, il va prendre cette partie-là. Quand je vais écrire de la

partie-là. Quand je vais écrire de la doc, il va me le dire. Donc c'est juste des instructions qui vont s'appliquer quelle que soit la tâche que vous lui demandez. Ensuite, si on revient sur la

demandez. Ensuite, si on revient sur la documentation du de la customisation de copilote, il va avoir des fichiers prompt, des agents de skill et des custom agents. Je vais pas aller dans

custom agents. Je vais pas aller dans MCPU, ça fait partie d'autres systèmes.

On va se limiter au fichiers relativement simple. Le prompt file,

relativement simple. Le prompt file, c'est quelque chose qui est historique dans Gitup Copilot. On peut avoir des commandes dans d'autres outils qui sont la capacité lorsque vous avez posé deux trois fois la même question, on se dit

"Bah mais tiens, en fait celui-là, j'aimerais bien le réutiliser." Et en fait, c'est relativement simple parce que ce que je peux faire ici, c'est si j'ai besoin d'un prompt, je vais pouvoir dire "Allez hop, je crée un nouveau

prompt." Alors là, moi je les mets dans

prompt." Alors là, moi je les mets dans mon fichier, hein, je le mets dans mon répertoire. On parlera un petit peu

répertoire. On parlera un petit peu justement des des des défis autour de ça. Et je vais lui dire fr. Donc moi ce

ça. Et je vais lui dire fr. Donc moi ce que je veux ici c'est que tu me répondes tout le temps quand je pose quelque chose. Donc là c'est quelque chose qui

chose. Donc là c'est quelque chose qui va être réutilisable tout le temps.

Réponds-moi en français et en majuscule avec plein d'emmodis.

Donc là moi je vais vous montrer un truc tout bête he là c'est vraiment basique dans le contexte de copilote. Et ça

c'est spécifique à copilote. Je vais

pouvoir lui dire également moi ce que j'aimerais bien c'est que tu utilises un modèle particulier. Quand tu fais ça, je

modèle particulier. Quand tu fais ça, je t'autorise uniquement à utiliser le G5 Mini, ce qui va permettre quand on fait des promes de contrôler également sa consommation des premium request.

Aujourd'hui dans Vitup Copiot, on travaille pas avec des tokens, on travaille avec des premium request en fonction du modèle que vous utilisez.

Donc là, si je ferme tout, j'ai plus de contexte. Bah, j'ai plus de contexte,

contexte. Bah, j'ai plus de contexte, plus de j'ai un contexte qui va être uniquement là. Systématiquement, dès que

uniquement là. Systématiquement, dès que je fais ça, j'ai mon nouveau prompt qui est là, vous voyez, slashfr et qui va s'appeler "Pux-tu me dire alors what is docker ?" Comme ça, il va il devrait

docker ?" Comme ça, il va il devrait répondre en anglais. en français

normalement docur et il va utiliser mon prompt et il va travailler comme ça.

Donc ça c'est une première partie. Moi

ce que j'ai fait ici, alors je vous en parlerai dans une seconde. Ce même

prompte, je vais utiliser en bac. J'ai

un prompt ici qui est euh hop hop hop mon end point c'est quand je veux créer une API Java, j'ai fait un prompt où je lui dis quand tu vas créer un nouveau produit, je veux vérifier que tu

as bien tout ce qu'il vaut. Je veux que tu utilises Toud dou, je veux que tu crées une branche. Et après, tu vas créer une entité Java. Tu vas utiliser ces annotations. Et un point qui est

ces annotations. Et un point qui est important, prenez cette habitude quand vous travaillez parce que vous voyez par rapport à la qualité des agents et cetera, vous avez du code existant dans votre application. Plus vous allez

votre application. Plus vous allez guider Lia pour lui dire "Je veux que tu codes comme ça, plus ça va être efficace." Par exemple là, quand je vais

efficace." Par exemple là, quand je vais cliquer ici, je lui dis "Le le le l'entité, je veux que tu la codes comme celle qui existe déjà dans mon projet."

Comme ça, il va copier la même façon de travailler plutôt que le laisser deviner. Moins on va avoir besoin de

deviner. Moins on va avoir besoin de deviner ou laisser lien à deviner, mieux ça sera. Donc ça c'est les promptes.

ça sera. Donc ça c'est les promptes.

Mais on s'est aperçu que l'inconvénient des promptes, c'est de laisser de devoir laisser la décision à à l'utilisateur de faire une tâche particulière.

Et là, c'est Entropique qui a sorti ça, qui a sorti la notion de skills. En

fait, comment on continue de spécialiser vos agent, votre IA par rapport à un besoin métier ou un besoin technique.

Les promes sont intéressants, les instructions sont intéressantes, mais ce qui pourrait être vraiment intéressant, c'est simplement de dire à copilote quand je te pose une question, alors quand je dis copilote et les

autres, quand je te pose une question, quand je te demande quelque chose, regarde d'abord si tu as pas une connaissance particulière qui pourrait aider à faire ça. Exactement comme vous.

Là, c'est faut vraiment moi je pense aujourd'hui qu'il faut vraiment voir les agents et les choses comme un pas comme un humain mais dans la même réflexion que dans avec laquelle vous travaillez.

Si je vais vous prendre un exemple tout bête.

Ici j'ai un prom vous voyez.

Est-ce que tu peux me créer un un fichier Terraform dans le répertoire qui s'appelle IAC pour déployer une nouvelle base Snowflake dans Azure ? et tu dois

me proposer des régions. Si je lui demande rien, c'estàd que moi j'arrive sur votre projet, vous me demandez ça probablement je vais faire du Google, je vais regarder, je vais faire un copiercollé d'interaforme Snowflake et

cetera et c'est tout ce que je vais faire. Donc là ce qui se passe, voyez,

faire. Donc là ce qui se passe, voyez, je lui ai demandé explicitement de me poser des questions. Donc il me propose des régions. Donc ça c'est le côté un

des régions. Donc ça c'est le côté un peu magique de Lia, c'est que maintenant il faut vraiment demander à copilote de vous poser des questions. Contrairement

à un humain, il va pas se lasser. Vous

pouvez lui demander 100000 questions, il va il va vous la vous pouvez demander toujours plus de détails, il va le faire. Contrairement à votre product

faire. Contrairement à votre product manager qui au bout d'un moment sera fatigué et va vous dire, je sais pas ce qu'il va vous dire mais vous vous débrouillerez. Donc là, je lui ai

débrouillerez. Donc là, je lui ai demandé de répondre à cette partie-là et il va me faire un terraforme. Il va me faire un terraform dans cette région là.

Très bien parce qu'il sépare les terraformes et cetera. Mais en fait, il y a quand même une forte probabilité qui se plante. Pourquoi ? Parce que

quelle version du du plugin provider Snowflex faut utiliser ? Moi, j'en sais rien. Dans votre entreprise, peut-être

rien. Dans votre entreprise, peut-être que vous allez toujours prendre les dernières. Dans votre entreprise, vous

dernières. Dans votre entreprise, vous allez peut-être dire "J'ai besoin une telle version."

telle version." Ce qu'on va faire en fait, c'est qu'on va créer ce qu'on appelle une skills qui va permettre de faire ça en se guidant sur ce que je lui ai demandé. Donc je vais prendre

exactement le même promèle.

Alors quel modèle j'avais pris ? Bah

Claud Opus. J'avais pris un modèle assez avancé. Je prends exactement le même

avancé. Je prends exactement le même prom. Je vais dans un autre projet qui

prom. Je vais dans un autre projet qui s'appelle context engineering demo. Je

démarre une nouvelle chose. Même

contexte. OK. Bam. Je vais vous expliquer après ce que j'ai fait pour préparer ce travail. mes ingénieurs, mes équipes de développeurs expérience, mes mes experts du domaine ont créé ce qu'on

appelle une skills. Et cette skills, vous voyez la première chose qu'il a fait quand je lui ai demandé, il m'a dit "Je veux créer un terrafile pour je vais regarder si j'ai des skills qui sont disponibles dans mon projet. Comme j'ai

des skills qui sont disponibles dans mon projet, je vais les appliquer. Donc

quelle région je dois utiliser ? Bon, je

vais les dire West US." Et vous voyez là, il a été cherché tout seul la version du provider qui convient. Donc

on va attendre la création du fichier.

Donc quand j'entends quelqu'un qui me dit aujourd'hui oh j'aime pas utiliser parce que ça code pas comme je veux ben je lui dis simplement bah dis-lui ce que tu veux et tu verras qu'il va coder comme tu veux. C'est vraiment ce comportement qu'il faut avoir. Et là

vous voyez là il a été cherché la version du GitHub Snowflex. Donc on va aller voir sur le projet Terraform.

Normalement la dernière relice c'est 2.13. Donc il a été la chercher et c'est

2.13. Donc il a été la chercher et c'est exactement le même prom. Mais en fait ce qui s'est passé c'est que dans ma partie quand je lui ai demandé de le faire, il

a été comprendre que j'ai besoin d'un snowfleck. Il a été voir dans le skills.

snowfleck. Il a été voir dans le skills.

Et le skills, en fait, c'est un répertoire dans lequel vous avez un point MD qui décrit le comportement et qui décrit quelque chose qui est très important, c'est cette description.

Ça qui va être utilisé par Lia pour comprendre est-ce que je dois utiliser cet issue ou pas. C'est vraiment comme ça qu'il faut euh écrire vos skills. Et

ensuite, je lui ai demandé "Je veux que tu génères un ter à forme." Et regardez ce que j'ai fait là. Je lui ai écrit explicitement, "Je veux que systématiquement quand tu as besoin du provider, tu ailles le chercher sur GitHub." Donc si vous avez quelque chose

GitHub." Donc si vous avez quelque chose de très particulier à faire, faut lui dire alors faut mettre des majuscules à la rigueur, faut dire "Attention, je veux absolument que tu fasses ça." Tu as interdiction de modifier du code et cetera. Et là dans ma référence, bah je

cetera. Et là dans ma référence, bah je vais avoir le command pattern que je vais utiliser. Donc il va coder comme

vais utiliser. Donc il va coder comme j'ai envie et je lui ai donné un exemple de fichier à la rigueur que je voulais avoir.

Et là vous voyez même prompte comportement même prompte même modèle comportement. Alors c'est pas j'ai pris

comportement. Alors c'est pas j'ai pris un modèle moins puissant. Bon il a fait le travail donc c'est parfait. Donc la

skills en fait va permettre de guider l'IA vers ce qu'on a besoin de faire. Et

ce qui est intéressant maintenant en fait, les skills deviennent des outils qu'on va on va pouvoir remplacer les promptes et les commandes par les skills. Parce que regardez dans Gituble

skills. Parce que regardez dans Gituble ici, si je tape Terraform, comment il s'appelle ? Il s'appelle Snowflex.

s'appelle ? Il s'appelle Snowflex.

Voyez, je peux directement l'appeler ici. C'estd que soit je laisse Lia

ici. C'estd que soit je laisse Lia choisir ma compétence, soit je le explicitement par un slash. Ça ça va beaucoup changer. Je pense que dans les

beaucoup changer. Je pense que dans les mois à venir, on va faire énormément énormément énormément de skills. Je vais

prendre deux trois skills que j' une une skills que j'aime bien utiliser on en parlait avec Arthur, c'est on utilise la même sur cette partie là et qui est intéressante dans la partie aussi

l'impact que ça va avoir. Je vais sur mon projet front.

Euh alors vous voyez, il m'a écrit en français en majuscule avec des emojis très intéressants. Donc ça c'était le

très intéressants. Donc ça c'était le prom démarre une nouvelle conversation.

Est-ce que vous voyez, il y a quelque chose qui est assez particulier, c'est que j'utilise pour les premiers utilisateurs de GitUP Copilot, on disait attention le contexte ça va être ce qui va être ouvert ici. Maintenant moi ça c'est plus quelque chose que j'utilise.

J'ai quasiment alors je suis pas encore passé au mode où j'ai que le chat. Ça

quand j'ai besoin de ça, je fais du je fais du terme de la Calme.

Mais par contre j'utilise ça pratiquement que pour de la revue de d'IF en fait de ce qui a été généré par L. Je ne tape quasiment plus jamais de

L. Je ne tape quasiment plus jamais de code. Quand je tape du code, c'est

code. Quand je tape du code, c'est souvent des markdown pour décrire mes instructions, donner des exemples et cetera. Là, je vais vous montrer quelque

cetera. Là, je vais vous montrer quelque chose que un agent que j'ai fait. Je

reviens sur les différents types pour terminer cette partie-là. Donc, on a vu les instructions globales, les instructions qui sont spécifiques à un

type de fichier, à une localisation, à une action particulière. Les promptes,

je vous invite à remplacer plutôt les promptes par les skills aujourd'hui. Euh

ça devrait parce que ça va beaucoup plus riche. On a des scripts qu'on peut

riche. On a des scripts qu'on peut lancer à l'intérieur et les custom agents.

Si on prend l'exemple de mon euh de mon provider Terraform, c'est pas un bon exemple dans ce cas-là, mais si on prend un exemple de quelqu'un qui fait de l'infrastructure à code et que vous avez des VM à faire et que vous voulez guider

en fonction de ce que vous avez besoin, si vous faites de l'anciible ou si vous faites du terraform, vous allez pas utiliser les mêmes règles. Vous allez

probablement utiliser les mêmes règles de sécurité. Donc le l'instruction sera

de sécurité. Donc le l'instruction sera la même. Tous ces ports là doivent être

la même. Tous ces ports là doivent être fermés. ces ports là sont ouverts, les

fermés. ces ports là sont ouverts, les adresses IP sont sur cette rente, sur cette sur cet intervalle d'adresse et cetera. Donc là, vous allez continuer de

cetera. Donc là, vous allez continuer de faire des instruction. Par contre, je vais mettre une casquette d'expert en cible ou d'expert euh euh terraform ou de front ou de

back. Typiquement, moi ce que j'ai fait

back. Typiquement, moi ce que j'ai fait dans mon projet, dans ce projet-l, j'ai créé un un custom agent, ce qu'on appelle un custom agent. Ici, vous

voyez, vous pouvez en rajouter. J'ai

créé un custom agent que j'ai appelé QA analyste et d'ailleurs, il y en a un qui existe par défaut dans GitHub, dans la CLI, dans les autres IDE, dans dans VS Code, c'est le mode plan. Quand vous avez une

tâche compliquée à faire, vous commencez toujours toujours par le mode plan. Vous

allez sur le plan et vous lui dites "Est-ce que tu peux me faire quelque chose ?" Il va préparer le travail. En

chose ?" Il va préparer le travail. En

fait, il va préparer un énorme prompte pour toujours commencer par un plan.

Toutes les IA modernes utilisent le plan. et ça permet ensuite de

plan. et ça permet ensuite de l'implémenter. Et en fait le plan, vous

l'implémenter. Et en fait le plan, vous pouvez voir ce que c'est. D'ailleurs, si

je vais ici dans VS Code, si je fais plan, vous allez voir à quoi ça correspond. Toujours pareil, je vais

correspond. Toujours pareil, je vais vous montrer un petit truc. Je suis un planning agent et tu t'arrêtes dès que tu veux faire l'implémentation, tu n'es pas responsable de l'implémentation.

Alors, il y a plein plein de choses.

Pour vous rappeler comment ça fonctionne, vous allez dans VS Code Configure et ici, vous avez tous vos agents, le custom agent et le plan. Ça

vous donnera une idée à partir de ce planlà. Moi, j'ai créé un plan qui

planlà. Moi, j'ai créé un plan qui s'appelle un agent qui s'appelle QA Analyste dont le rôle est de regarder mon code s'il manque des tests unitaires

ou des tests d'intégration.

Euh donc la façon dont je le teste, c'est très simple. Et là par rapport à la question de la personne qui posait si je dois spécialiser sur du front, ça peut être une idée. Bah là je vais faire ici, je vais lui dire Q analyste analyse

le projet.

J'ai pas besoin d'aller plus loin parce qu'en fait tout le prom va être dans le custom agent. J'ai mon chapeau d'expert.

custom agent. J'ai mon chapeau d'expert.

Donc il va travailler, il va prendre un certain temps. Donc j'ai déjà lancé

certain temps. Donc j'ai déjà lancé cette tâche précédemment. Je vais vous montre. Donc il va prendre les fichiers

montre. Donc il va prendre les fichiers qui vont bien par rapport à ça. Je vais

aller ici. Je vous ai montré ici. Voilà,

je l'ai fait tout à l'heure il y a 1 heure, on préparait la réunion. Je vous

montre le résultat. Le prompte, il est tout bête. Analyse project avec le QA

tout bête. Analyse project avec le QA analyste, il a regardé, il m'a dit "Voilà ce qui est couvert, mais tes tests unitaires sont couverts à ce niveau-là. Par contre, il manque tous

niveau-là. Par contre, il manque tous ces tests euh unitaires dans tes services. Les tests end toend. Voilà ce

services. Les tests end toend. Voilà ce

qui manque, voilà ce qu'il y a et voilà ce qui manque. Moi, je ne suis pas assez confiant aujourd'hui dans l'IA pour lui dire implémente-moi tous ces tests parce qu'en fait c'est la partie qui va être

critique dans mon implémentation.

Qu'est-ce que je vais faire ici ? Alors

si vous regardez en bas, alors sauf qu'il l'a pas parce que je l'ai déjà fait. Donc ce que je vais faire, c'est

fait. Donc ce que je vais faire, c'est que je vais switcher à il m'avait posé deux questions. Est-ce que tu veux

deux questions. Est-ce que tu veux implémenter ou est-ce que tu veux créer des issues ? En fait, moi je vais lui

des issues ? En fait, moi je vais lui dire dans ce cas-là, ce que je veux que tu fasses, c'est que tu crées des issues.

Et donc, il va prendre le plan, tout ce qui est le résultat de ces tests, le résultat de l'analyse du code, il va prendre mes skills qui sont là pour créer des issues et il va créer des

issues et des subissues dans mon projet.

Donc là en fait je suis parti j'ai fait le travail d'un technique d'un expert QR entre guillemets. Je lui spécifié

entre guillemets. Je lui spécifié exactement ce que tu voulais. Tu bosses,

tu prépares le travail, tu crées ensuite des issues. Là, il va appeler les

des issues. Là, il va appeler les serveurs MCP de Gitter, mais si vous êtes sur Girira, sur Azure Devox ou sur d'autres plateformes, vous avez pareil la possibilité de vous connecter. Et ce

qui est intéressant dans le dans l'issue et dans le dans la skills que j'ai créé, que j'ai utilisé ici, euh Gitub issues, il va regarder s'il y a pas des doublons avant de créer, il va pas il va regarder

s'il y a pas déjà une issue qui correspond ça. Donc là, il va créer les

correspond ça. Donc là, il va créer les issues. Mais supposez que vous avez une

issues. Mais supposez que vous avez une idée. Vous savez le cerveau il marche

idée. Vous savez le cerveau il marche très très vite. Je une nouvelle idée. Je

vais dire "Oh tiens, j'ai une nouvelle idée." Le marketing m'a posé cette

idée." Le marketing m'a posé cette question. Je vais dire peux-tu hop je

question. Je vais dire peux-tu hop je passe en mode agent et je vais lui dire hop parce que je veux que ce soit détaillé, je vais quand même faire de l'opus.

I need a new screen to add to upload user profile image. Can you create an issue ? Vous

image. Can you create an issue ? Vous

voyez, je switch le contexte très vite.

Tac, je crée une issue. Je crée je crée une demande pour créer une issue. Donc

là, en fait, ce qui est intéressant, vous voyez, je travaille sur plusieurs agents en parallèle dans VS Code. Vous

pouvez faire la même chose dans votre dans la ligne de commande. Donc là,

normalement, je suis en train de créer ici les issues, il est en train de les créer, c'est parfait. Je vous reviendrai dessus. Et là, j'ai une autre idée. J'ai

dessus. Et là, j'ai une autre idée. J'ai

le support qui m'appelle et qui me dit "I cannot connect to port 888".

Can you create for ? Je veux pas qu'il analyse le code.

for ? Je veux pas qu'il analyse le code.

J'ai juste envie de créer l'issue parce que c'est une t sur laquelle je vais travailler par la suite. Lia, il faut pas l'avoir uniquement comme vous vous permettant d'aller plus vite sur certaines tâches. Surtout surtout vous

certaines tâches. Surtout surtout vous allez vraiment exploiter l'IA quand vous allez pouvoir travailler en parallèle sur plusieurs tâches. C'est là où vous gagnez énormément.

Si vous êtes capable de déléguer plein de tâches en parallèle, vous allez voir votre une augmentation de votre productivité, même si c'est un terme que j'aime pas, qui va être assez conséquent. Je vais aller sur mon projet

conséquent. Je vais aller sur mon projet et on va regarder les issus qu'il est en train de créer.

Hop, je vais ouvrir un nouveau terminal.

Hop, il manque un B.

Il y a des questions sur quand il crée des quand il crée des issus, est-ce qu'il est capable de rajouter des tags, des choses comme ça automatiquement ?

Ouais, en fait non, là ce qu'il va faire c'est que euh il a rajouté automatiquement. Alors

tiens, c'est bizarre quand il a pas créé, il doit me demander de valider.

Non, c'est voilà, elle est là celle-là.

Si on regarde ici, il a créé un template fate. Il a utilisé mon template feature.

fate. Il a utilisé mon template feature.

Il a rajouté des tags AI on announcement. Il a deviné que c'était un

announcement. Il a deviné que c'était un announcement et moi dans mon skill, je lui ai demandé. Donc j'ai la liste des fonctionnalités. J'ai un premier

fonctionnalités. J'ai un premier acceptance de critériat donc une première itération. Et logiquement je

première itération. Et logiquement je dois avoir un bug qui a été créé.

Voilà Canot Connect the back and et vous voyez il a utilisé un système différent.

il a utilisé un template différent parce que template moi je l'ai pas mis dans mon ripoitub il est dans la skill la skill est dit tu

vas utiliser le serveur MCP tu vas regarder si tu dois faire un update tu vas vérifier si ça existe et compagnie et quand tu vas créer l'issue tu vas te t'appuyer sur les templates et là j'ai

les templates qui sont dans ma skill et l'endroit où je lui ai dit juste pour la la démo, je lui je lui avais rajouté cette ligne ici hop en lui disant disant rajoute le label h

donc quand tu crées comme ça, on sait que ça vient d'eau. Donc en fait tout ça c'est vraiment une autre façon de travailler. Ça va permettre d'accélérer.

travailler. Ça va permettre d'accélérer.

Et avant de te donner la main, je voudrais montrer un tout petit truc. Le

dernier la dernière démo que je veux montrer, c'est que là, j'ai pas généré beaucoup de codes. Euh enfin pas généré du tout, je crois. Mais par contre, si j'ai besoin d'écrire des tests, voilà comment je vais le faire. Je vais aller dans mon issu. Alors moi je suis sur

GitHub donc j'ai l'avantage de pouvoir utiliser pas mal de choses. Donc si j'ai envie d'ajouter un end to end testing, ce que je vais faire, je vais demander depuis ma poudre depuis mon issue à

Gitub de hop, crée-moi automatiquement euh le test de façon autonome dans un agent qui tourne sur le

cloud avec soit le choix du modèle, soit le choix de l'agent euh si j'ai besoin de spécialiser. Et là en fait, il va

de spécialiser. Et là en fait, il va créer une branche, créer une P request et il va travailler tout seul dans son coin. Et comme ça, je vais valider ce

coin. Et comme ça, je vais valider ce test là. Je vais le merde.

test là. Je vais le merde.

Dans mon cas, j'avais mis mon template ici. Moi, je l'ai mis dans le skills, tu

ici. Moi, je l'ai mis dans le skills, tu vois, il est ici. Mes templates, ils sont dans le skills. Comme ça, tu peux les adapter à tes besoins. Donc quand tu vas les chercher sur copilot, dernier petit truc, quand j'ai besoin de

spécialiser quelque chose, si je ne connais pas, je cherche sur copilot instruction. Voilà, par exemple ici,

instruction. Voilà, par exemple ici, j'ai un j'ai migré. Alors, si vous êtes familier avec Java, vous connaissez l'application Pet Clinique de Spring

Boot. Elle a été entièrement réécrite en

Boot. Elle a été entièrement réécrite en deux prompt par GitHub en DNET. Mais

moi, j'y connais strictement rien à DNET. Quand j'ai open sourcé le projet,

DNET. Quand j'ai open sourcé le projet, les experts DNET m'ont dit "Oui, mais tu utilises pas ça, tu utilises pas c Bah oui, j'utilise pas ça, j'utilise pas si parce que j'y connais rien au DNET.

Comment je deviens un expert de DNET ?"

Moi jamais. Mais par contre, je peux demander à Gitup Copilot de le devenir.

Donc ce que je vais faire, c'est que je vais aller sur Copilot, je vais aller sur les agents ici. Hop, on va le faire ensemble.

Et vous allez voir la problématique qu'on a ici, c'est comment je partage tous ces fichiers avec mon entreprise parce que je vois pas demander à chaque développeur de cliquer à chaque fois.

C'est ce que je fais là, ce qui est pas grave. Mais dans l'entreprise, on va

grave. Mais dans l'entreprise, on va avoir des choses un peu plus critiques à faire. Ah, qu'est-ce qui se passe là ?

faire. Ah, qu'est-ce qui se passe là ?

Voilà, un petit bug. Là, je vais chercher C#ARP.

Hop. Alors, DNET

même DNET, j'arrive pas à à à l'écrire.

Il est où ? C#ARP

C. Voilà, ça peut-être mieux. Donc, j'ai

un un expert C# C#ARP. Donc, je

l'installe dans VS Code. Hop, il est installé dans mon projet finale. Donc,

je le mets dans Gitub. Vous pouvez pas mettre dans Claude ou dans d'autres endroits, c'est chaque expert. Je vais

très vite, j'en prends un deuxième, j'ai un janitor et je vais lui demander une tâche particulière. Et là, je vais

particulière. Et là, je vais volontairement je vais passer par la ligne de commande juste pour le faire.

Je pourrais faire exactement le même prom dans Gitab. Ici, je vais ouvrir le term je vais ouvrir le terminal. Je là,

je sais pas, les agents pas pas été montés parce que je viens juste de les installer. Sont pas encore installés.

installer. Sont pas encore installés.

Donc ce que je fais c'est que je redémarre mon copilote.

Si je regarde ici, j'ai des j'ai des agents. Voilà, j'ai C#ARP Expert et

agents. Voilà, j'ai C#ARP Expert et Janitor. Donc j'ai maintenant un expert

Janitor. Donc j'ai maintenant un expert parce que je vais lui dire, je vais lui dire e euh can you alors on va le faire avec deux agents en parallèle. Flit. Can

you use the C#PNET janitor C#ARP expert with the model opus

4.6 to analyze the code on create report in expert.mD

expert.mD le moi j'ai pas envie qu'il modifie le code. J'ai envie de comprendre un nozer

code. J'ai envie de comprendre un nozer agent with euh C#ARP.net janitor

with euh code GPT 53 codex euh for the same doc. Donc là en fait je demande à

same doc. Donc là en fait je demande à Gitubilot, il va me démarrer deux agents en parallèle avec deux custom agents en parallèle deux profils pour m'écrire de la doc. Alors l'idée c'est quand

la doc. Alors l'idée c'est quand généralement quand on va vers une flotte d'agent, c'est tout pour faire la même tâche. On va plutôt écris-moi la doc

tâche. On va plutôt écris-moi la doc d'un côté, rajoute-moi des tests et cetera. Mais là, vous voyez là, il va

cetera. Mais là, vous voyez là, il va créer un C#ARP expert en utilisant Opus, un C#ARP.net janitor en utilisant 5.3.

Et vous voyez que malgré les tipo, il a été capable de d'analyser le code. Et en fait ce qui se passe ici, c'est que GitHub Copilot va m'aider à comprendre mon code pour

l'améliorer. Et vous voyez, je lui ai

l'améliorer. Et vous voyez, je lui ai pas demandé de modifier le code, je lui ai demandé crée-moi de la doc. Comme ça,

je vais essayer de comprendre. Si j'ai

des questions, je demande de la clarification. C'est pour Rachid pour te

clarification. C'est pour Rachid pour te pour te pour répondre à ton commentaire.

En fait, c'est que là, je lui demande pas d'écrire le code directement, je lui demande de me former, utiliser l'IA pour apprendre des choses. Donc, on va revenir à une question qui est plus importante, c'est comment on partage

tous ces fichiers ? Parce que là, moi je vous avais vu, je les ai cherché sur copilot et aussi comment on en rajoute et on les manage. Je pense que Arthur, tu as plein d'informations à nous partager au Yes. Il y a il y a pas mal de questions

Yes. Il y a il y a pas mal de questions auxquelles on répondra, je pense, à la fin, sur justement comment tu euh sélectionnes. Est-ce que c'est plutôt

sélectionnes. Est-ce que c'est plutôt une instruction ? Est-ce que c'est

une instruction ? Est-ce que c'est plutôt un skill ? Est-ce que c'est plutôt un custom agent et cetera ?

Évidemment. Euh hop. Donc attends, je repartage mon écran. Tac. C'est parfait.

Effectivement la vraie question en fait et le vrai sujet c'est que pour nous ces différents éléments donc les standards, les commandes et les skills, ça doit être quelque chose qui doit être en 2026

presque plus important que le code. Pour

moi, c'est c'est plus important que le code parce que c'est des choses qui vont amener les agents à générer du code.

Donc quelques erreurs dans un fichier d'instruction, c'est peut-être des milliers d'ignes de code qui vont pas être bonnes. Donc en fait, il faut les

être bonnes. Donc en fait, il faut les traiter ces items, ces skills, ses commandes, ses standards vraiment comme des entités qui sont super importantes.

Et donc il faut un système de review et donc il faut un système de partage et cetera. Il faut pouvoir les tester. Donc

cetera. Il faut pouvoir les tester. Donc

toutes ces questions effectivement, on essaie d'y répondre avec Pacm. Donc

c'est un projet qui est open source he je vous partage le repo ici. Vous pouvez

ben utiliser la solution, tester, rajouter des stars adhésyif sur le repo mais en gros comment ça fonctionne ? Ben

dans Pacmine vous allez retrouver tout ce que tu as montré TUG des standards qui sont un peu toujours vrais. C'est

des règles sur le code par exemple sur comment j'utilise des dogers. des

exemples positifs négatifs de code, des commandes qui sont comme tu dis vont peut-être être regroupées avec les skills sur plutôt des workflow. Donc

comme tu mettais tout à l'heure, c'est des commandes, c'est j'ai étape 1, j'identifie un bloc de code dupliqué, étape 2, je fais de test et cetera et des skids avec le skidopu par exemple

que que tu avais ici. Et tout ça, on va pouvoir les regrouper dans des packages.

Donc on va faire un package frontend, un package architecture hexagonale, un package packend, ce que vous voulez. Et

ces différents packages vont pouvoir être distribués sur plusieurs repos et sur plusieurs types d'agents en même temps. C'est-à-dire que je peux dire que

temps. C'est-à-dire que je peux dire que j'utilise copilote et puis cl et puis cursor et juni et puis guid et cetera.

Donc en fait ça ça va me permettre de centraliser et distribuer facilement ces différents outils. La question c'est

différents outils. La question c'est comment est-ce que je crée justement tout ça ? La première chose que les

tout ça ? La première chose que les équipes nous remontent c'est OK, je sais qu'il faut communiquer avec les agents, mais qu'est-ce que je leur transmets comme information et comment je capture tout ça ? En fait, quand vous utilisez

tout ça ? En fait, quand vous utilisez Pacmine dans l'onboarding, on vous dit d'installer Packmine CLI. Et quand vous installez Pacmine CLI, vous faites un Pacmine init sur un projet. Il va vous dire tiens qu'est-ce que tu utilises ?

Est-ce que tu utilises cloud, code cursor, copilot et cetera. Et quand je lui dis bah j'utilise par exemple copilote, il va me créer des skills via Packmind. Donc justement, c'est encore

Packmind. Donc justement, c'est encore un exemple de comment on utilise des skills. Je vais avoir un skill pour

skills. Je vais avoir un skill pour créer des commandes, créer des standards, un skill pour créer des skills et cetera. Et donc l'intérêt c'est que pour toutes les personnes de mon projet qui ont même pas besoin de

connaître Packmine, vu que les skills sont rajoutés dans GitHub là ici dans le point GitHub, en fait j'ai amplifié mon copilote avec des capacités de Pacmine et donc quand je dis à copilote ben

crée-moi une skill à partir de comment est-ce qu'on utilise notre design système, ben là il va me poser des questions. Il va utiliser mon skid qui

questions. Il va utiliser mon skid qui est ici et cetera et il va aller ben créer le skid qui va bien, il va le mettre dans Pacmine et cetera. En fait,

je vais pouvoir créer très facilement des choses intéressantes sur le projet.

On a un cas avec un client par exemple qui avait fait une migration de Postman vers Pght qui a pris un projet type qui est le projet cible qui a dit du coup avec copilote et Pacmine, bah crée-moi

les skills autour de la migration et cetera. Et derrière, il s'est servi de

cetera. Et derrière, il s'est servi de ça pour dire sur un projet qui était encore en Postman, fais-moi un audit et montre-moi ce qu'il faut que je modifie et cetera. Donc en fait, on va comme ça

et cetera. Donc en fait, on va comme ça spécialiser effectivement les agents et ce qui est intéressant après, c'est c'est quoi le cycle de vie de ces outils ? Parce qu'évidemment, s'ils sont pas à

? Parce qu'évidemment, s'ils sont pas à jour, ça va être une catastrophe. Et

donc pour ça, on est en train de développer différents outils. Justement,

par exemple, si je dis euh à copilote tiens, ben utilise ma commande ou mon skill pour faire une extraction de composant React et cetera, il va le faire. Et si je lui dis ajoute à la fin

faire. Et si je lui dis ajoute à la fin une étape qui est de créer un item storybook par exemple, donc je lui demande de modifier en fait ce qui m'a fait, on va avoir une skide de Pacmine

ici qui est à gauche qui s'appelle Capture Playbook Update qui va aller donc elle fonctionne avec un hook aussi.

On a pas parlé un tuc des hook mais les hook c'est des choses déterministes qui sont lancées quand vous terminez une conversation par exemple avec copilote.

Et donc à la fin d'une conversation on a le hook de copilote du coup qui va trigger le skill qui est ici qui va aller faire une sorte de résumé de la conversation qui va regarder s'il y a pas des éléments intéressants et qui va

demander à l'utilisateur tiens est-ce que tu veux pas que je rajoute des tables justement dans ton truc et cetera. Et ce qui est intéressant, c'est

cetera. Et ce qui est intéressant, c'est que ces skills, on peut en avoir plein d'autres du type "Je vais me brancher avec le MCP à Slack ou à Teams, je vais regarder les communications de la semaine et je vais créer des choses à partir de ce qui s'est dit dans la

semaine où je vais regarder les commentaires de merge request sur GitHub sur le dernier mois et en fonction des commentaires de merge request, ben je vais te je vais te proposer justement de mettre à jour tes trucs." Et une fois

que tout ça en fait c'est mis à jour côté euh VS Code, en fait ça arrive dans Pac-Mine mais c'est pas automatiquement déployé pour tout le monde parce que comme jeai dit c'est des fichiers qui sont importants. Donc s'il y a quelqu'un

sont importants. Donc s'il y a quelqu'un qui de le soir à 17h30 dit à copilote "Arrête de faire des tests M2N parce que j'ai pas de temps, j'ai envie de me barrer." Il faut pas que il y ait la

barrer." Il faut pas que il y ait la règle arrête de faire des tests M2 à partir de 17h qui soit valable pour tout. Donc évidemment tout ça arrive en

tout. Donc évidemment tout ça arrive en fait dans une partie review changes qui est ici. Et là on peut voir que j'ai des

est ici. Et là on peut voir que j'ai des commandes, des standards et des skits qui sont en attente de validation. Et

donc on voit par exemple que j'ai une modification que j'ai faite ici où j'ai édité des étapes, j'ai rajouté une nouvelle étape qui est d'ajouter une storybook et cetera, une étape storybook

et donc là je vais pouvoir ben modifier, valider tout ça et cetera. Donc on a une histoire de gestion de droit dans Pacmine, on a une histoire un peu de structure comme dans nos où vous avez une organisation qui est votre

entreprise et ensuite des sous-parties qui sont des équipes en fait. Et donc

vous allez pouvoir comme ça ben promouvoir un standard ou un skill au niveau organisation, l'utiliser dans plusieurs équipes et cetera. Et le but de Pac-Mine, ben justement c'est de pouvoir gérer tout ça, voir qu'est-ce

qui est déployé en live sur quel repos, qu'est-ce qui est à jour, pas à jour, on gère les versions et cetera. Donc en

fait, c'est vraiment ce système de passage à déchet, de gouvernance et cetera qui est assez important parce que sinon on ne gère comme tu disais Tug, c'est uniquement des fichiers markdown dans des repos. Donc on commence à voir

des entreprises qui font du copiercollé de markdown d'un repos à l'autre et cetera. Bon, ça devient un petit peu un

cetera. Bon, ça devient un petit peu un petit peu le bazar. Donc c'est assez important justement de bien pouvoir gérer tout ça. Donc si vous voulez utiliser Pac-Mine, c'est c'est open source et cetera. On a un autre projet

d'ailleurs que je peux présenter qui est le contexte évaluator qu'on a sorti il y a il y a quelques semaines qui permet d'évaluer la qualité de notre contexte.

Donc on met notre repitup ou un repos même, vous pouvez l'installer en local et une fois que vous le lancez en fait vous allez alors je je vais en prendre un au hasard, ça va ça va peut-être pas être gentil. Non, je vais prendre celui

être gentil. Non, je vais prendre celui de bon, j'en sais rien. Je prends

Locktach. Ah, les pauvres, ils ont pas une très bonne note. Donc en fait, ce qui se passe, c'est que quand on lance sur un projet, on va aller regarder est-ce qu'il y a des fichiers justement agent MD, est-ce qu'il y a des fichiers skill et cetera ? Est-ce qu'ils sont à

jour, est-ce que ils ont pas d'opposition justement, est-ce qu'ils sont pas trop gros ? est-ce que non est cohérent et cetera et on va proposer des suggestions. On va dire bah en fait ton

suggestions. On va dire bah en fait ton fichier agent MD bah il faut le changer.

Bon là dans ce cas-là par exemple c'est il y a pas de fichier agent MD donc et tu as pourtant 578 fichiers Ruby. Donc

c'est c'est quand même pas terrible. Et

en fait on va pouvoir proposer des rédiations. Donc soit directement dans

rédiations. Donc soit directement dans Pacmine soit dans l'application. Ici on

va vous dire ben on vous propose de modifier ça et cetera. Je vais partager le lien du contexte évaluateur. C'est un

c'est un petit projet annexe hein mais qui est assez intéressant pour se rendre compte de est-ce que notre projet est high ready ou pas, on va dire. Donc

est-ce que on a assez de contexte justement pour fonctionner ?

Donc c'est tout ce que je vais présenter sur Pacm parce qu'il nous reste assez peu de temps. Mais j'aimerais bien du coup bah discuter avec toi tu de c'est

quoi pour toi le bon ratio, tu vois de fichier Agent MD de skill et cetera et quand est-ce que tu choisis est-ce que c'est plutôt un custom agent, un skill

ou quelque chose qui doit être dans une instruction ? C'est quoi tes tes règles

instruction ? C'est quoi tes tes règles un petit peu si tu devais rajouter des choses dans le copilote ?

Alors alors le bon ratio euh honnêtement je sais pas. Euh dans le sens où tiens, j'ai l'impression que je partage je partage encore mon écran ou pas ?

Ouais, tu le partages encore. Ouais,

je sais plus comment on le on arrête le partage mais bon. Pas grave.

Euh en fait là-dessus, j'ai pas vraiment de règle. Alors plus parce que je manque

de règle. Alors plus parce que je manque d'expérience sur des très gros projets.

D'accord. Chez chez sur le projet GitHub. Alors là, je suis pas un core

GitHub. Alors là, je suis pas un core développeur de GitHub, mais on a plein de fichiers d'instruction et on a quelques agents et on commence à avoir des skills, mais c'est c'est les skills, c'est quand même relativement récent.

Donc j'ai pas sur le ratio, je sais pas.

Par contre sur la façon dont je réfléchis quand je vais rajouter quelque chose, j'ai systématiquement un copilot inscription, l'équivalent du cloud. MD

ou d'agent. MD à la racine qui va définir les choses de base. Notamment un

exemple tout bête, c'est que dans ce fichier là ou dans celui celui qui référence, c'est que si je fais du front, je vais lui dire toutes mes tout le code source du bac, il est à tel endroit. Ce qui me permet en fait à

endroit. Ce qui me permet en fait à copilote d'aller chercher automatiquement des choses dans un autre IPO s'il y a besoin. Ce qui me permet de lancer dans mon dans mon front euh

liste-moi toutes les API qui ont été implémentés sur mon client, qui ont été implémentés sur le serveur qui ne sont pas encore sur le client. Bah là en fait ça je le mets dans mon copilot inspection parce que c'est global ce

lienlà. Les instructions

lienlà. Les instructions spécifiques, c'est vraiment plus pour des règles métier à un instant Té.

Alors, quand des règles du métier, ça va être les règles de collage pour le front et cetera parce que je peux les typer et je peux les euh les orienter par Alors là, je parle de fichier instruction dans le

GitHub où je vais pouvoir dire c'est étoile étoile/SRC/TS par exemple et je vais pouvoir dire c'est pour mes tests ou pour mes taxes, je vais pouvoir orienter. Ils ne seront utilisés qu'à cet endroit-là. L'avantage

de faire ça, c'est que ça va aussi réduire ce qu'on va envoyer.

C'est-à-dire que si vous avez des agents, des très gros fichiers partout, il va il va les mélanger. Donc l'idée

c'est plus d'essayer de les targeter.

Mais c'est assez empirique.

Les promptes, je pense que je vais plus les utiliser parce que je vais faire les skills. Quitte à ce que la skill soit

skills. Quitte à ce que la skill soit pas très compliquée, mais je vais faire des skills parce que il peut deviner tout seul comment la prendre. Et je peux faire slash. Je peux faire slashur si

faire slash. Je peux faire slashur si j'ai besoin de contacter Arthur. Euh

alors ça sera une skill au ça ça change pas beaucoup. Euh ce que j'aime avec les

pas beaucoup. Euh ce que j'aime avec les skills, c'est qu'on peut lancer des scripts, on peut faire des choses qui sont beaucoup plus compliquées. Donc si

vous avez besoin, là je suis en train de travailler sur une petite démo.

Imaginez, vous êtes pas sur Gitub, vous avez pas d'automatisation pour faire vos release notes pour un pour un projet.

Bah ce que vous allez pouvoir faire, c'est que je fais une skill qui va aller chercher dans mon ripo git le dernier dif qui va analyser le résultat et cetera. Donc là, vous pouvez faire des

cetera. Donc là, vous pouvez faire des choses qui sont vraiment compliquées et ça c'est vraiment puissant. Les custom

agents, moi je le vois vraiment comme je mets un chapeau, c'est une un personnage, je suis un expert d'un domaine particulier.

Si on revient aux instructions et aux skills, quand je vais créer une issue, c'est indépendant du langage de programmation, c'est indépendant de ce que je fais. Donc skill, elle va être réutilisable quel que soit ce que je

fais. Si j'ai des instructions, ça va au

fais. Si j'ai des instructions, ça va au langage de programmation. Mais par

contre, si j'ai une instruction autour de la sécurité, elle est globale que je sois un expert Java, un expert TPS script ou un expert shell, une powers shell. Donc moi, mon custom instruction,

shell. Donc moi, mon custom instruction, c'est quand j'ai une tâche très un chapeau à mettre très particulier. Je

suis expert de la qualité, je voilà comment je veux que tu travailles avec le code. Je suis j'ai besoin de faire un

le code. Je suis j'ai besoin de faire un audit. C'est un c'est un agent très

audit. C'est un c'est un agent très particulier qui fait que de l'audit, qui diminue le nombre d'appels euh qui va diminuer le nombre d'outil. Donc c'est

plus vraiment le chapeau que vous allez mettre. Je suis un codeur ou je suis

mettre. Je suis un codeur ou je suis quelque chose qui veut réagir de cette façon-là. Quelqu'un parlait d'écrire de

façon-là. Quelqu'un parlait d'écrire de la doc. Bah, typiquement pour écrire de

la doc. Bah, typiquement pour écrire de la doc en français ou autre chose, je vous invite à faire une instruc un custom agent qui est un doc writer dans

lequel vous allez dire je veux utiliser Mermaid et et Mark, je veux toujours que tuécrives en français. Comme ça, quand vous mettez votre chapeau j'écris de la doc, il va savoir faire tout seul. Vous

allez pas avoir oh zut, il est en train de m'écrire du code en plus de écrire de la doc. Non, il est là uniquement pour

la doc. Non, il est là uniquement pour écrire de la doc et c'est de la doc fonctionnel ou technique. Il pourra vous pourrez lui dire même dans ce cas-là quand tu écris de la doc, je veux que tu lances un serveur MCP Playw pour faire

des captures d'écran de mon autre partie là et tu as spécialisé cette ce custom.

Ouais, super. Ouais. Ben écoute, je vois qu'il y a il y a encore pas mal de questions, je pense dans le dans le de répondre à certains trucs. Donc

Johan, pour les tables, oui, tu peux mettre dans les dans le template français ou anglais. Alors, c'est vous avez vu, moi j'ai switché un petit peu, j'ai principalement tapé en anglais.

Alors, c'est plus parce que je travaille en anglais, d'accord ? C'est c'est une habitude. Euh on a beaucoup de clients

habitude. Euh on a beaucoup de clients qui font tout en français. Par contre,

ce qu'il faut pas faire, c'est mélanger.

D'accord ? Ça, c'est très important.

Vous avez une nouvelle fonctionnalité dans la CLI, le GitHub euh qui est amusante, qui est euh euh qui qui m'a dit "Attention, tu as

mélangé là." Je peux lui dire "Peux-tu

mélangé là." Je peux lui dire "Peux-tu m'analyser ?" Je vais faire en anglais.

m'analyser ?" Je vais faire en anglais.

Can you analyze allessions ?

My sessions.

And improve.

Vous voyez pourquoi j'ai besoin de lire, c'est que je sais même pas commenter.

Improve.

My use of fit. La CL, il va analyser toutes les

fit. La CL, il va analyser toutes les sessions. En fait, ce qui est

sessions. En fait, ce qui est intéressant avec cette tâche et vous pouvez faire la même chose dans la entre guillemets, vous pouvez demander à copilote ou à Li qu'est-ce que vous me

conseillez de faire. Là, en fait, ce que fait cette commande, elle est expérimentale encore dans la CLI. Quand

vous avez indexé, c'est que il y a une commande index réindex là, elle va stocker tous vos promptes et tout ça dans une base de données SQL Lite et après quand vous pouvez l'analyser, poser des questions

sur votre historique. Et là, elle est en train d'analyser, j'ai trouvé, vous voyez, il fait du SQL sur la base locale. Tout est local, il y a rien

locale. Tout est local, il y a rien d'envoyer. Donc là, c'est aussi une

d'envoyer. Donc là, c'est aussi une façon d'améliorer son travail. Et par

rapport au français ou anglais, ben là typiquement, il pourra peut-être te dire bah arrête d'écrire en anglais parce que tu écris tellement mal en anglais qu'il faudrait peut-être préférable d'écrire en français.

vaut mieux faire un bon une bonne phrase en français qu'une mauvaise phrase en anglais. Ah,

anglais. Ah, quand j'ai vu la fonctionnalité de réindex avec la base de données SQL local sortir, ça montre vraiment une direction des différents outils vers on va essayer de rentrer dans une boucle

d'amélioration continue par rapport aux discussions qu'on a avec les agents, par rapport aussi au commentaires de merger West et cetera. Donc c'est vraiment là où c'est intéressant, tu vois, nous dans Packmind, on a vraiment travaillé sur la

partie technique et humaine de comment tu gères la validation, le cycle de vie et cetera. Et maintenant avec copilotes

et cetera. Et maintenant avec copilotes et différents outils, c'est très facile de faire des skills pour des communications slack pour tu vois il y a des clients qui font un skill qui est je me branche à Gira et je regarde les bugs

que j'ai eu de dernier mois et en fonction des bugs, propose-moi des skills ou des instructions qui me permettent d'éviter les bugs que j'ai eu. Par exemple, s'il y a un bug qui est

eu. Par exemple, s'il y a un bug qui est il y a eu trop d'appel HTTP d'un coup et cetera, bah tout seul, il va aller chercher, tu vois, et regarder dans le code le fix qui a été fait et nous proposer une instruction. Donc c'est

assez infini en fait. Je pourrais dire connecte-toi à Médium, regarde tous les nouveaux articles qui sortent sur React et fais-moi chaque semaine, tu vois, un truc sur ça et cetera.

Donc c'est vraiment super de pouvoir ben créer des skids comme ça qui vont être utilisés ponctuellement et qui sont sur une verticale précise pour s'assurer

justement que que tout est bon.

et et ensuite sur là ce qu'on a pas montré aussi c'est tous les autres agents qui existent dans GUP qui vont être le coding agent, la revue de code, la CQ et cetera. Mais tout le travail

que vous faites en terme d'investissement sur comprendre comment marche le contexte, c'est quelque chose qui va vous aider dans toutes les phases de développement. Vous voulez

de développement. Vous voulez transformer Gitup Copilot en un outil qui va vous permettre d'aider à écrire des requirements, ben en fait, vous allez créer une skills ou créer un template. D'ailleurs, je pense qu'elle

template. D'ailleurs, je pense qu'elle existe. Euh si je regarde ici dans les

existe. Euh si je regarde ici dans les skills, hop, il y a pas mal de repos d'ailleurs de marketplace comme ça.

Et ici en fait là, j'ai alors c'est pas moi qui l'ai fait, celui-là il existe.

C'est il va définir voilà quel est ton quel est ton rôle. Ton rôle c'est d'interviewer l'utilisateur, de poser des questions. Ensuite tu vas faire des

des questions. Ensuite tu vas faire des recurbants, ça va ressembler à ça. Le

template à la fin va ressembler à ça et cetera. En fait ce qui va se passer que

cetera. En fait ce qui va se passer que aujourd'hui on va souvent voir des développeurs et des développeuses qui vont travailler énormément très proche du code avec l'IA. Vous allez percevoir que vous allez au moment vous allez

accélérer, il y a un déclic. Il y a un moment où je dis "Mais attendez là, ça fait une semaine, j'ai pas écrit une ligne de code. J'ai développé des features, j'ai fixé des bugs, je n'ai pas touché à ma ligne de code." Je sais

que ça peut choquer certains, mais c'est comme ça. C'est c'est vraiment ce qui

comme ça. C'est c'est vraiment ce qui arrive aujourd'hui. Quand vous arrivez à

arrive aujourd'hui. Quand vous arrivez à cette étape-là, on passe à l'étape suivante. Comment je peux accélérer ce

suivante. Comment je peux accélérer ce qui est en aval et en amont, c'est-à-dire l'écriture d'aspect, la valide d'aspect, la clarification d'une spécification pour ensuite passer pareil sur la partie

Qet et cetera puisque en fait la revue de code va se faire de la même façon.

C'est-à-dire que la une petite démo que j'aime bien faire sur la revue de code.

Alors, je vais faire très rapidement ici. Supposez que euh je fais euh euh

ici. Supposez que euh je fais euh euh c'est comment s'appelle mes Jason ? FR

Jason, je fais une petite faute de frappe. D'accord ? Celle-là, je l'ai

frappe. D'accord ? Celle-là, je l'ai raté. Je me suis trompé. J'ai fait un

raté. Je me suis trompé. J'ai fait un copiercollé, j'ai raté quelque chose.

Avant de faire le commit, ce que j'aimerais bien, c'est faire une revue de code. J'ai pas besoin d'aller sur la

de code. J'ai pas besoin d'aller sur la pool request. Je vais ici dans mon

pool request. Je vais ici dans mon change. Soit je le fais dans la ligne de

change. Soit je le fais dans la ligne de commande et je peux lui dire alors ici pareil, on a plein de façons de le faire. Je peux faire un review ici.

faire. Je peux faire un review ici.

Euh ah ben il y a pas j'ai pas dû activer la bonne fature mais il est ici.

C'estd qu'ici je peux faire un review. Hop.

un review. Hop.

D'accord. il va me revoir le dif où je le fais ici et il va me revoir. Et là en fait il va analyser avant mon commit en respectant les instructions. Alors moi

j'en ai pas fait spécifique pour la revue de code. Ce qui répond à Albert c'est que vous pouvez spécifier les de la revue de code pour cette partie-là.

Et vous voyez, il m'a dit ici oh tiens regarde tu as fait une faute de frappe.

Celle-là il y a 9 chances sur 10 si vous avez un énorme fichier Jason comme celui-là que vous l'ayez raté quand vous allez faire la pouquest dans la sans lia.

Tous ces trucs là de test, de commentaires, de typo de typo dans les fonctions, dans les paramètres et cetera vont être pris en compte. Là, j'ai même pas connecté donc je peux faire apply et connect. Et là, bah pareil, j'ai dû

connect. Et là, bah pareil, j'ai dû faire des fautes de fois, il manque la lig euh Ouais, c'est très bien. Voilà.

Euh et ça, je l'ai pas fait dans le dans la poudre request. Si là, c'est indépendamment si vous êtes sur GitHub ou pas, ça marche côté client.

Évidemment, si vous êtes sur vous allez avoir la possibilité de faire la même chose ici. Et là, on a un impact très

chose ici. Et là, on a un impact très fort sur ici. Je peux demander à copilote de

ici. Je peux demander à copilote de faire hop la poudre de faire la revue de code. Ça c'est un impact fort sur la la

code. Ça c'est un impact fort sur la la le la vélocité de vos projets. On a des métriques. Alors, je l'ai pas fait sur

métriques. Alors, je l'ai pas fait sur mon projet, je le ferai plus tard. On va

voir le nombre de jours que vous gagnez parce qu'en fait énormément de temps sont perdus dans la revue de code. Dia

va vous aider sur cette partie-là. Vos

instruction et votre façon de préparer le travail est la même que vous soyez pour écrire du code, pour comprendre du code, pour de la doc, pour sécuriser, alors pas au sens ça remplace pas les sastrés

outils.

Ouais, c'est top. Et il y a quand on parle de context engineering ou de harness engineering qui est le terme encore plus précis, il y a aussi une chose, c'est que c'est important de mélanger du non

déterminisme avec les instructions que tu vas avoir en aval et en amont, tu vois, sur la partie revue de code ou quand tu vas écrire du code avec

copilote et aussi un peu de déterminisme avec des customer, avec du sonar, avec des outils comme GitUp code quality qui

ou du prétilleur ou du tout ce que vous voulez ou des tests euh ou des tests unitaires, des tests end ou du typage fort avec des langages fortement typés, des choses comme ça.

En fait, tous ces checks un peu déterministes qui vont assurer la la qualité et surtout la cohérence de ce qu'on a, il deviennent super importants en plus des instructions de copilote parce qu'effectivement ben c'est non

déterministe. Donc une fois de temps en

déterministe. Donc une fois de temps en temps ça peut passer à côté d'un skid ou d'une instruction. Donc c'est vraiment

d'une instruction. Donc c'est vraiment bien de mixer les deux. C'est que je pas précisé mais dans Pacmine pour tout ce qui est standard donc vraiment des instructions avec des exemples de codes positifs négatifs on génère une règle de

custom d'inter justement qui permet de checker de manière déterministe dans la C ou dans l'IDE ou en précommit hookement pour voir si jamais il y a des soucis ou quoi. Mais ce qui est bien c'est que

quoi. Mais ce qui est bien c'est que c'est déterministe, que c'est pas cher parce que c'est un programme qui se lance et on est sûr au moins d'avoir un filet de sécurité. Donc ça va rentrer super. Ben merci tout le monde. Ouais,

super. Ben merci tout le monde. Ouais,

je sais pas si tu veux.

Non, le seul petit truc, c'est lié un peu aux questions d'Albert tout ça, c'est euh ces fichiers là, ça se teste comme quand vous testez du code. Alors,

il y a pas de test automatique et il y a pas de test d'intégration. Mais quand

vous créez vos instructions, quand vous créez vos vos skills et tout ça, faut les tester euh et ne pas hésiter à partager avec vos équipes. Ça c'est très très

vos équipes. Ça c'est très très important. et Pac-Mine est vraiment

important. et Pac-Mine est vraiment intéressant pour ça, pour diffuser la formation et automatiser cette partie.

Tout à fait. Ouais, c'est très lié effectivement c'est un on revient sur une problématique un peu culturelle et humaine après qui est comment est-ce que on communique dans les équipes sur ce qui est important comme pratique ou pas,

comment est-ce qu'on valide ça ? Comment

est-ce qu'on partage d'une équipe à l'autre ? Donc on retrouve un peu les

l'autre ? Donc on retrouve un peu les côtés chapter dans les entreprises, chapter front, back cetera, communauté de pratique où on discute autour de tout ça. Sauf que là, c'est plus juste pour

ça. Sauf que là, c'est plus juste pour des êtres humains où on doit travailler sur la formation et cetera et la revue de code manuel, mais ça va être pour créer des instructions pour les agents.

Et toi, tu utilises le parallèle de d'un développeur qui a trop picolé le jeudi soir TUG. Moi, je prends paradise

soir TUG. Moi, je prends paradise souvent avec, tu vois, les White Walkers dans Game of Thrones ou des zombies qui sont toujours qui sont jamais fatigués en fait et qui font toujours la même chose tout le temps. Donc effectivement,

c'est pas déterministe mais on garde une cohérence et ça devient super intéressant.

Super. Ben, merci beaucoup. Je partage

juste petit point important pour parce qu'il faut vraiment ce soir vous êtes ici dans le col, c'est vraiment intéressant et que vous êtes intéressé euh là chez Spotify he les meilleurs développeurs. Donc les meilleurs

développeurs. Donc les meilleurs développeurs, c'est c'est pas les parce que il y a souvent cette discussion c'est pour les frontes, c'est pour les juniors et cetera. Maintenant,

c'est-à-dire que l'impact des développeurs les plus expérimentés, au bout d'un moment, vous voulez vous intéresser au code le plus pointu et ça vous pourrez toujours le faire mais également vous allez vous concentrer sur la valeur que vous ajoutez dans

l'entreprise, c'est donner du business, donner des features. Chez Spotify, le CEO disait que depuis décembre, les meilleurs développeurs ont pas pissé la ligne. Ils ont pas touché à la ligne de

ligne. Ils ont pas touché à la ligne de code. Ça a été fait par la gentille.

code. Ça a été fait par la gentille.

et Spotify utilise Cloud Code Unitot et je pense qu'il doit avoir du curseur mais en tout cas je sais qu'ils utilise ces deuxl c'est vraiment un travail où on est en train de changer énormément

énormément notre façon de travailler et de façon provoquante provocative je sais plus quel est le bon mot mais je vais demander à lire c'est si vous pensez que votre métier c'est de pisser la ligne

vous êtes pas dans la bonne direction et ça moi j'ai trois fils qui sont développeurs qui ont 22 26 2 22 24 et 26 ans. Euh et pourtant, j'ai pas peur pour

ans. Euh et pourtant, j'ai pas peur pour eux. Par contre, je leur ai dit qu'il

eux. Par contre, je leur ai dit qu'il voulait rester dans le développement.

Soit vous êtes un gourou d'un domaine particulier, euh vous êtes l'expert de l'indexation des bases de données et vous allez bosser en C++ dans la gestion de la mémoire et des accès de disque.

C'est pas le cas.

Donc si vous êtes en informatique de gestion, l'informatique technique et cetera, il faut apprendre à coder avec Lia. Et d'ailleurs, je pense que les

Lia. Et d'ailleurs, je pense que les vieux comme moi, on a beaucoup à apprendre des jeunes développeurs qui ne qui vont avoir appris à coder avec Lia.

Je suis complètement d'accord.

C'est une source d'inspiration et peut-être un sujet pour un autre webinaire. [rires]

webinaire. [rires] Tout à fait. Il y a il y a des avenirs mais effectivement il faut prendre la vague et il faut réussir à avoir de l'impact dans les entreprises et à créer de la valeur. On n jamais été payé pour créer des lignes de code. On a toujours

été payé pour créer de la valeur dans les entreprises. Effectivement avec

les entreprises. Effectivement avec l'IA, bah ça nous permet de d'avoir une chaîne de bout en bout de création de valeur qui est plus efficace. J'aime

bien dans la démo quand tu montres TUG l'interface carrément de Gitup directement pour dire ben depuis la merge request je peux assigner et cetera. Les gens oublient ça. On est

cetera. Les gens oublient ça. On est

toujours dans notre IDE focalisé sur l'IDE avec le code. Mais en fait la chaîne complète, tu vois, depuis le Figma jusqu'à la création de ce qu'il y a derrière ou même du Gitub Park et

cetera. Ouais. Voilà. ou le

cetera. Ouais. Voilà. ou le

gitup/copilote.

J'aime beaucoup cette interface parce que voilà, on change de paradigme, on est plus sur c'est quoi l'intention, c'est quoi l'idée qu'on a derrière, qu'est-ce qu'on veut créer et euh ça

marche super bien quoi.

Oui. Moi, on on a bes Vous avez besoin d'un sujet pour faire un webinaire, pour faire pour répondre à un CFP, utilisez lien, inspirez-vous. Après vous faut

lien, inspirez-vous. Après vous faut adapter euh faut adapter le contenu, faut que ça soit humain, mais par contre inspirez-vous de tout ça.

Super. Ben merci tout le monde. Merci tu

encore une fois pour ta participation et puis pour tous les échanges comme on disait. Voilà, si jamais il y a je vois

disait. Voilà, si jamais il y a je vois qu'il y a encore beaucoup de questions, je vais repartager aussi hop mon LinkedIn. N'hésitez pas à retrouver TUG

LinkedIn. N'hésitez pas à retrouver TUG aussi sur LinkedIn le mail. hésitez pas

à nous poser des questions de manière de manière asynchrone et à la prochaine pour un autre webinar.

Merci encore Tug. Salut tout le monde.

Bonne fin de journée du coup. Ça va ?