Ne pensez pas que faire travailler une intelligence artificielle (IA) à sa place soit facile. Certes, pour accomplir des tâches simples, obtenir des réponses à des questions existentielles ou connaître le temps de cuisson des œufs durs, il est facile de taper ou de formuler sa question.
Le développement logiciel demande un peu plus de recul avant de déléguer à un assistant numérique. Entre l’expression du besoin et la réalisation de ce dernier, des activités différentes vont s’enchaîner : le recueil du besoin, le choix de la technologie, le codage, … C’est le propos de mon blog et j’en ai écrit une série.
Vous connaissez l’expression, “Touche à tout, expert en rien”. C’est le problème des IA. Si vous voulez qu’elle fasse votre travail, il va falloir avant cela lui donner un cadre. Et ce cadre se définit suivant trois axes déjà évoqués : le rôle, le contexte et la tâche ou RCT.
Le Rôle
Comme un acteur, votre assistant a besoin de savoir ce que vous attendez de lui. Sera-t-il le l’analyste qui va recueillir le besoin de l’utilisateur afin de le transposer dans un dossier qui détaille de manière efficace les fonctionnalités attendues ? Ou bien l’architecte qui va proposer le contexte technique adapté au besoin ?
Il faudra aussi le rôle du codeur spécialisé dans la technologie choisie ? Et le chef de projet qui s’assure que chaque étape est bien réalisée et conforme à la demande du client ? Et on peut multiplier les rôles pour s’assurer que le résultat soit conforme au besoin et survivra dans le temps parce que bien écrit.
Le Contexte
Il s’agit du cadre sur lequel va travailler l’assistant numérique. Par exemple, l’agent développeur doit connaître la technologie retenue pour développer l’application et la fonctionnalité qu’il doit implémenter. L’agent analyste doit connaître le métier de son utilisateur et les fonctionnalités qu’il attend pour son application.
Vous pouvez définir le contexte ou vous pouvez demander à un agent sur une étape précédente du projet de le définir pour son collègue. Ainsi, l’agent analyste définit les fonctionnalités que va implémenter l’agent développeur.
Le contexte d’un agent peut dépendre des choix d’autres agents. Souhaitez que le chef de projet vous en informe. Sinon vous verrez à la réception.
La tâche
Dernier élément à décrire pour vos agents, les tâches auxquelles ils sont affectés. Très simple à décrire pour le développeur. Par exemple : “Écrit dans le langage attendu le composant métier xxx défini par l’analyste. Écrit l’interface qui permet d’y accéder. A la validation, enregistre-le en utilisant le service yyy”.
Des tâches, il va falloir en décrire des centaines, même pour une simple application. Soit vous endossez d’autres rôles pour alimenter votre agent développeur, soit vous demandez à d’autres agents de le faire pour vous. Dans ce cas, faites en sorte qu’ils aient une tâche “Faire valider par le grand patron”, avant de les autoriser à créer de nouvelles tâches pour d’autres assistants.
—
Vous l’aurez compris, devenir un développeur fainéant est tout un art. Celui de décrire les bons rôles, de valider les décisions de tels agents qui vont impacter le contexte et les tâches d’autres agents et même parfois leur rôle.
Déléguer ses missions à des assistants numériques, c’est comme être le maître de jeu d’un jeu de rôle. Vous avez préparé un scénario en décrivant les environnements, les acteurs, et des situations clés où vous espérez qu’ils progresseront jusqu’à la résolution de l’histoire. Restez sur le qui-vive, les joueurs sont toujours surprenants.
La fainéantise, c’est tout un travail. Certes, vous pouvez faire le minimum. Dans ce cas, vous aurez de la chance si votre application fonctionne. Et ce sera un miracle si par la suite votre équipe virtuelle arrive à ajouter de nouvelles fonctionnalités auxquelles vous aurez pensé.