Article rédigé par
Youenn Duval
Directeur Technique
Les livres et chapitres Neobooks, c’est quoi ?
Où de la difficulté de conceptualiser quelque chose et de lui donner un nom.
Tout commence avec un constat issu de nos expériences personnelles. Le support c’est plein de tâches répétitives, aussi bien techniques (diagnostiquer/résoudre) qu’administratives (remplir et qualifier un ticket). Les approches sont sensiblement toujours les mêmes, on répare souvent les mêmes problèmes et généralement de la même manière. Les petits bobos du quotidien sont la plus grosse dépense de temps dans un service de support.
Nous avons donc voulu conceptualiser un outil qui nous permettrait de réduire fortement tout ce temps dépensé dans une répétition pleine de vacuité intellectuelle !
1 – Conceptualisation
Comment s’y prendre ? Facile !
Le Deep Learning, la solution à tout ?
Cette fameuse boîte noire qui sort des réponses magiques toutes faites !
Eh bien pas de ça chez nous. Non, non.
Non, cher·e lecteur·ice·s, pas de boîte noire chez nous. Certaines mauvaises langues préciseraient que c’est surtout qu’on n’y connait rien en Deep Learning, les outrecuidants ! Que nenni 
! *tousse*
Bref, revenons à nos moutons cahiers des charges !
Notre idée
Notre idée, c’est d’avoir un outil qui permette d’enchaîner tout un tas de diagnostics (sur le poste d’un utilisateur ayant déclaré un problème) avec l’objectif de pouvoir résoudre le problème en toute autonomie. Si ce dernier point n’est pas possible, escalader le ticket à des technicien·ne·s en remplissant le ticket et le qualifiant correctement.
Et si ce n’était pas déjà assez compliqué, on veut que ce soit accessible à tous·tes les technicien·ne·s, quel que soit leur niveau. On veut que tout soit transparent. N’importe qui doit pouvoir intellectualiser un automatisme aussi bien dans son ensemble que dans le détail de la ligne de commande qui effectue une action précise.
Nous sommes des gens curieux et notre outil doit pouvoir aussi bien tourner en autonomie que de servir de tutoriel géant et vivant pour étancher la curiosité et la soif d’apprendre d’un·e technicien·ne.
On doit donc pouvoir créer des scripts (bash, powershell ou autres). Des scripts qui font tous la plus petite action possible de manière à pouvoir être réutilisés dans d’autres arbres. Ensuite, on va assembler ces scripts les uns après les autres. On va même pouvoir choisir un script ou un autre en fonction du résultat du script initial. Ainsi on va construire un arbre de diagnostic/résolution. Le tout avec un outil visuel. Oui, quelques lignes de code peuvent déjà rapidement devenir abscons, imaginez des centaines !
Comment et quand lancer le bon livre Neobook
Rien qu’avec ça il y a de quoi s’occuper mais il reste des questions ! À commencer par comment et quand lancer le bon arbre de diagnostic ? (En vrai y’en a plein d’autres mais je vais faire court, dites-moi merci ! 😇)
On va donc y rajouter un chatbot assez futé pour comprendre la demande initiale et lancer le bon arbre.
Mais… (oui, y’a beaucoup de « mais ») il y a de nombreux cas où un script classique n’est pas suffisant. On peut avoir besoin de poser une question à un utilisateur ou à un de ses supérieurs (pour donner des droits sur un dossier par exemple, une approbation). On peut vouloir appeler un autre arbre de diagnostic en plein milieu plutôt que de le recopier dans son intégralité. Il faut aussi tout bêtement gérer les escalades ou les résolutions des tickets, les informations du ticket, passer des informations d’un script à un autre, etc. Ce ne sera donc pas juste des scripts, il y’aura d’autres types d’action.
Quand on a fini de conceptualiser, on va devoir l’expliquer. Aussi bien à nos futurs clients qu’aux développeurs qui vont nous aider à créer tout ça (Oui, j’ai pas de garage, donc je peux pas faire le story telling classique de la silicon valley ! ça se jouait à si peu pourtant… 🥲).
Pour être sûr de pouvoir expliquer chaque concept clairement, il va donc falloir tous les nommer. Eviter les confusions, aussi bien au sein de l’application qu’en interactions avec d’autres. Rien de pire que d’utiliser un terme usité au quotidien dans notre métier et de lui donner un sens différent. Il va souvent falloir faire des comparaisons, parfois des métaphores mais surtout éviter les confusions.
2 - Le nommage des chapitres
On a donc choisi le concept de livres et de chapitres Neobooks. « Mais pourquoi ?! » me diriez-vous. Déjà, à notre connaissance, il n’y a pas d’autres produits avec ces terminologies. Ensuite on est parti d’un concept qui nous parlait.
Les livres dont vous êtes le héros ! ⬇️
Vous connaissez peut-être le concept ?
Ce sont des livres jeux. Chaque chapitre se termine par un choix et en fonction de votre choix, vous allez à une page et un chapitre précis (il y’en a souvent plus d’une centaine).
Vous pouvez avoir une fiche de personnage pour prendre des notes durant votre aventure, gérer vos points de vie, inventaire etc. Vous pourrez donc relire plusieurs fois le même livre avec des choix différents et de fait une histoire et une fin différente (quand votre personnage ne meure pas à cause de ses choix en plein milieu de l’aventure ! Non fallait pas rentrer dans cette caverne ou dormait un Golbarg à trois têtes).
C'est là qu'est notre comparaison principale
Un livre c’est une aventure (un ticket), une enquête via le diagnostic, on peut être amené à sortir de l’histoire au milieu du livre (escalader un ticket), on peut aller jusqu’à la fin et résoudre l’intrigue en toute autonomie. Chaque action (script, question à l’utilisateur, escalade etc.) est un chapitre. L’exécution d’un livre, s’il débute toujours de la même manière, pourra suivre un chemin différent en fonction des analyses effectuées.
Cela rejoint également le concept où tout est intelligible, il n’y a pas de boîte noire, tout·e technicien·ne peut décider d’ouvrir les détails et de voir chaque ligne de script exécutée dans un livre et en prendre connaissance. Comme avec un livre dans vos mains, vous pouvez tout parcourir.
Mieux, aussi simple que de prendre du papier et un crayon, écrivez vos propres livres. Utilisez des chapitres déjà créés, assemblez-les différemment grâce à une interface graphique, apportez de légères modifications et/ou rajoutez les vôtres tel une fanfiction sur internet ou partez de zéro et créez un livre avec un ensemble de scripts maison pour un sujet important dans votre entreprise (typiquement autour d’une application métier avec une API par exemple). Dans les faits, ça ne se fait pas en 5 minutes. Il faut se former un minimum, il faut réfléchir à l’imbrication et son implication, il faut écrire ses scripts maison (on en fournit, on peut également vous accompagner). Cela prend du temps, on vous a dit, on ne fait pas d’IA magique ! 😁
Toute comparaison a ses limites
En revanche, toute comparaison ou métaphore a ses limites. Il y a plusieurs types de chapitre, ils peuvent exécuter du code powershell, envoyer des notifications, des demandes d’approbation, des messages à l’utilisateur ou encore appeler un autre livre. Et là, c’est rare qu’un livre dans la vraie vie vous demande de le poser, d’en lire un autre au milieu, avant de revenir à lui.
On vient donc de faire exploser la métaphore (et ce ne sera pas la seule fois…).
3 - Comment fonctionne un livre Neobook ?
Bon et sinon, concrètement ça donne quoi ? A quoi ça ressemble un livre ? Comment ça marche ?
Et bien si on ouvre un livre Neobook dans notre application pour voir à quoi ça ressemble, on pourra voir ça :
Chaque bloc est un « chapitre » et est ajouté et paramétré via cette interface en click bouton.
Chaque chapitre a de nombreux paramètres tel qu’un nom (il faut bien commencer quelque part), un type (script, question, approbation etc.) et bien d’autres.
Chaque chapitre ne peut avoir que deux sorties, une positive (en vert) et une négative (en rouge, c’est bien vous suivez !).
Dans l’image on peut voir 4 types de chapitres : des blancs (script), des rouges (Fin et escalade) des bleus (Lancer un autre livre) et un jaune (demande de confirmation/approbation).
Et tout cela s’exécute grâce au bot lors de la conversation avec un utilisateur comme on peut le voir dans cet historique.
Le cadenas 🔒 indique que le message n’est pas visible aux utilisateurs, mais uniquement aux technicien·ne·s.
Vous aimeriez en savoir encore plus ? Aller au-delà de cette lecture fort distrayante et en discuter ? En attendant que la doc’ complète soit en ligne, vous pouvez toujours demander une démo !
Articles qui pourraient vous plaire
