Le développement collaboratif de LLNG implique d’échanger ou d’éventuellement consulter les autres membres de l’équipe pour l’ajout, la modification ou la correction des différentes fonctionnalités. Un avantage majeur de ce mode de fonctionnement est également de pouvoir, en cas de besoin, demander de l’aide ou solliciter un conseil.
En outre, les décisions ou solutions sont prises ou choisies de façon collégiale ce qui est très gratifiant et rassurant pour les nouveaux membres. Ce mode de fonctionnement est très enrichissant mais impose le respect de règles ou conventions tant sur la forme que sur le fond.
Les échanges avec l’équipe, en particulier avec Clément Oudot qui a eu l’occasion d’installer LLNG dans différentes administrations ou entreprises tant en France qu’à l’étranger, m’ont permis d’aborder LLNG de façon plus large, avec une vue plus globale. En effet, je n’avais qu’une vision très « gendarmerie » de la manière dont était installé et utilisé le SSO, tout particulièrement en ce qui concerne le second facteur. Celui-ci n’étant pas encore en place au sein de la Gendarmerie nationale, je ne voyais pas comment il pouvait être mis en œuvre. La politique la plus répandue dans les autres organisations est la mise en place de TOTP ou de clefs U2F. L’emploi d’un second facteur y est imposé pratiquement à tous les personnels car ceux-ci doivent se connecter au réseau de l’entreprise depuis des postes connectés à Internet.
3.3.2 – Documentations
Tous d’abord, la politique Debian, très stricte au sujet de la fuite de données, interdit de référencer des ressources externes directement dans le code. Ceci nous a donc imposé de compiler la documentation en ligne dans des paquets spécifiques en plus de la rédaction des fichiers POD
Ensuite, toutes les caractéristiques de la solution LemonLDAP::NG sont détaillées dans la documentation disponible sur le site du projet https://lemonldap-ng.org/documentation/. J’ai consacré pratiquement tout le mois d’avril à lire et relire la documentation existante pour appréhender, comprendre et rédiger la deuxième partie de ce mémoire. Cet important travail de lecture et relecture de cette documentation a été un échange gagnant-gagnant tout comme les cours d’anglais que j’ai pu suivre sur mon temps de travail. En effet, la documentation ayant presque été intégralement rédigée en anglais par le fondateur du projet lui-même, des points qui peuvent paraître évidents ne le sont pas forcément pour un lecteur extérieur. Cette phase a donc également été l’occasion de la valider ou de la faire évoluer. Après plusieurs semaines d’interrogation et d’apprentissage, j’ai même pu être en mesure de relever et corriger quelques incohérences ! J’en ai profité également pour rédiger ou mettre à jour les pages relatives aux différents seconds facteurs d’authentification. Toute cette documentation ainsi que les menus et les échanges sur la plateforme de développement sont rédigés en anglais. Seuls les menus des interfaces sont traduits vers une dizaine de langues telles l’espagnol, le vietnamien, l’italien ou l’arabe. Les fichiers de langue sont mis à disposition de la communauté pour traduction sur la plateforme Transifex, un espace collaboratif de traduction.
Enfin, il est très important d’inclure des commentaires dans le code source et d’utiliser des constructions claires et détaillées pour permettre aux autres développeurs de reprendre ou poursuivre le code. J’ai donc pris soin de respecter cette règle et d’ajouter un maximum de messages de « debug » pour permettre de suivre les différentes étapes d’exécution, notamment pour permettre la correction d’erreurs.
3.3.3 – Règles, Conventions & Architecture globale
Pour faciliter la lecture et améliorer la maintenabilité du code, des règles d’usage et des conventions d’écriture m’ont été imposées lors de mon intégration à l’équipe. En effet, j’ai eu à apprendre à utiliser des outils comme (« PerlTidy », 2018) pour formater le code Perl et « yuiCompressor » pour minifier le code JavaScript.
De plus, ce qui m’a posé le plus de difficultés avec AngularJS, a été l’apprentissage du langage (« CoffeeScript », 2018). Il m’aura fallu environ deux semaines de pratique et lire le guide suivant : (Burnham, 2015). CoffeeScript est un langage de programmation, qui se compile en
JavaScript. Celui-ci ajoute du « sucre syntaxique » le rendant plus agréable à écrire comme à lire
afin d'améliorer la brièveté et la lisibilité du JavaScript, tout en lui ajoutant des fonctionnalités. Les particularités de CoffeeScript sont l’absence de caractère pour délimiter les blocs de code mais l’utilisation de l’indentation comme en « Python » et la déclaration des paramètres des fonctions avant la fonction elle-même ce qui est un peu perturbant au début. Le résultat est compilé de façon prévisible en JavaScript, et les programmes peuvent être écrits avec moins de code (typiquement un tiers de lignes en moins) sans effet sur la vitesse d'exécution.
L’architecture du projet LLNG est modulaire et m’a demandé une dizaine de jours pour bien l’appréhender. La structure de son arborescence peut être vue comme quatre composants indépendants, correspondants aux répertoires Portail, Manager, Handler et Common. Chacun de ces répertoires est basé sur le même schéma et contient, entre autres, les sous-répertoires « lib », « site » et « t » ainsi que les fichiers « MANIFEST », « bower.json », « README » et « debian/control ».
Les répertoires « lib » contiennent l’ensemble du code et des modules exécutables. Le nom de chaque module correspond à sa position dans l’arborescence. Dans « site », nous trouvons tous les fichiers concernant l’interface web notamment tous les CoffeeScript, les JavaScript générés, les
templates, le CSS et les fichiers de langues pour la traduction de l’interface utilisateur. Je terminerai
avec les répertoires « t » qui contiennent l’ensemble des tests de non régression. Ces tests représentent environ 40 % de l'ensemble du code de LLNG et leur temps d’exécution est d’environ 6 minutes ce qui commence à être important mais nécessaire. Ces tests de non régression ont pour but de s’assurer que toute nouvelle évolution ou modification ne « casse » pas une fonctionnalité existante.
Pour chaque répertoire correspondant à un composant de LLNG (Portail, Manager, etc.), le « MANIFEST » décrit l’ensemble des fichiers qu’il contient ce qui permet d’en vérifier l’intégrité. L’utilitaire « bower » est un outil logiciel de gestion des paquets. Il est utilisé pour vérifier et télécharger les mises à jour des librairies nécessaires à LLNG. Celles-ci sont décrites dans le fichier « bower » qui est lu par l’utilitaire éponyme. Le fichier « README » est un guide succinct d’installation spécifique à chaque module. Enfin, chaque arborescence de module contient un fichier « debian/control ». Il contient les informations les plus importantes sur le paquet source et sur les paquets binaires qui seront créés. Il permet surtout de préciser les dépendances. Il s’agit d’une des caractéristiques les plus puissantes du système de paquets Debian. Les paquets peuvent être liés entre eux et être dépendants, recommandés ou suggérés.