Image générée par Microsoft Designer

1. Introduction

Ce billet de blog servira également de cahier des charges pour un projet que j’ai en tête depuis longtemps. Il risque d’être très long car il va détailler absolument tout et sûrement évoluer (parce que j’ai pas brainstormé avec moi-même du coup j’ai sûrement oublié des choses, m’voyez 😃 ). Il détaille les attentes que j’ai sur la finalité de ce projet et décrit les besoins fonctionnels et non fonctionnels. La première partie du document présente le contexte et les objectifs de ce projet. La seconde décrit les spécifications à respecter pour que le projet soit concrétisé.

2. Description du projet

2.1 Présentation du contexte

On s’est tous un jour cassé la tête à créer une interface ASCII plus ou moins complexe, plus ou moins dynamique, en Powershell. Ou on a opté pour un module qui le fait très bien comme PSMenu. Sauf qu’on a également tous connu quelqu’un qui “ne veut pas s’embêter avec un prompt”, dont la simple vision d’un terminal lui donne de l’urticaire.

2.1.1 L’Intelligence Artificielle

Cette idée, que j’ai depuis très longtemps, n’est pas révolutionnaire mais elle m’intéresse par son côté challengeant et surtout, j’y vois une belle occasion de tester l’IA pour voir si oui ou non, ça vaut le coup.

2.1.2 L’existant

Il existe bien des solutions comme Windows Forms ou bien des classes DotNet mais, c’est pénible à réaliser pour le peu d’avantages qu’on y gagne (et en plus, à moins d’y passer 3j, c’est moche).

Il existe aussi plusieurs projets ou produits permettant de réaliser une interface Web, plus ou moins dynamique :

• Pglet : je suis tombé dessus pendant que je rédigeais cet article, je ne l’avais jamais vu avant ! Ca a l’air sympa, mais son utilisation me semble éloignée de ce que je veux (trop complexe pour “tout le monde”).
• Powershell Universal: Beaucoup le connaissent, c’est ma Rolls dans le domaine. C’est payant, assez cher je trouve pour ce que c’est (prix par hôte).
• Pode: Un projet que je suis depuis longtemps. Il se rapproche beaucoup de ce que j’ai en tête, une première version que j’avais fait il y a très longtemps était construite ainsi: des fichiers imbriqués avec du Powershell intégré dedans puis directement interprété.

2.2 Objectifs et enjeux

2.2.1 Enjeux

Les enjeux sont simples:

• Simplifier: une interface Web peut répondre à de nombreuses problématiques que l’on rencontre sur un terminal
• Partager: c’est un projet à temps perso, le soir après avoir couché les enfants et après les autres projets qui sont prioritaires. Aucun but lucratif. Si ça accouche de quelque chose, ce sera open source.
• M’améliorer: en effet ce n’est pas un projet inutile, je souhaite y mettre tout ce que j’ai pu apprendre ces dernières années, de la gestion de projet à la technique. Ainsi, je pourrais en tirer moi-même un vrai bénéfice: de l’expérience.

2.2.2 Objectifs

Les objectifs sont multiples :

1. Mettre en place une gestion de projet et terminer le projet sur une V1.0.0.
2. Réaliser des comptes rendus réguliers sur ce blog pour faire état des différents sujets: IA, avancée du projet, difficultés rencontrées et réussites
3. Imbriquer les différentes couches (HTML, JS, Powershell) d’une manière simple à comprendre et à utiliser (pour l’indicateur, ça sera vous via sondage/questionnaire 😃 ). L’utilisateur final doit pouvoir créer une interface via du code Powershell ou des fichiers à plat (selon le choix technique).
4. Déterminer si une IA est meilleure qu’une autre pour le Powershell (je n’utiliserai que des IA qui proposent une utilisation Web et gratuite)
5. Réaliser un outil fonctionnel avec 70% des fonctionnalités de départ

3. Spécifications non fonctionnelles

3.1 Contraintes techniques

3.1.1 Automatisation - Scripts

3.1.1.1 Langage

Ce projet portant sur Powershell, le langage sera donc celui-ci. Il devra pouvoir supporter le cross-plateform (donc v7+).

3.1.1.2 Stockage et partage

Les scripts devront être hébergés sur un dépôt public (pour la version main). Pour une question de simplicité et praticité, le dépôt sera Github.

3.2 Documentation

Tout devra être documenté et commenté. La documentation sera hébergée sur Github également.

3.4 Contraintes linguistiques

Le public visé n’étant pas forcément que Francophone, il faudra que tous les documents et scripts rendus publics soient english first.

4. Spécifications fonctionnelles

4.1 Serveur Web

Le serveur web qui hébergera l’interface devra être local et supporter l’authentification. Son port d’écoute sera modifiable. Il ouvrir directement l’interface une fois démarré. Il devra être accessible en HTTP (HTTPS dans le futur) via les méthodes GET ou POST.

4.2 Interface web

Doit être compatible avec les navigateurs par défaut. Son design devra reposer sur un framework CSS simple et léger. L’interface devra également gérer du JS, idéalement un framework simple et léger.

4.3 Imbrication

Pour répondre à l’objectif de l’imbrication des couches, il faudra créer un “système syntaxique” (oui c’est grave pompeux, désolé, j’ai pas trouvé mieux) pour intégrer les différents langages.

4.4 Modularité

L’outil doit rester modulaire. Si l’utilisateur veut pouvoir déplacer un élément à gauche ou à droite de l’interface, il faut que ce soit géré.

5. Conclusion

Pour conclure cet article, je n’ai pas de conclusion. J’ai certainement oublié des choses, je le mettrai à jour.