Activité professionnelles détaillées🔗

J'essaye de conserver trace de mes activités professionnelles au fur et à mesure du temps qui passse. Vous retrouverez ici une sorte de CV détaillé.

Ce projet consiste à évaluer les performances produites par le logiciel libre de SIG QGis sur un entrepôt de données géographiques sous Oracle Spatial. QGis permet d'accéder aux données Oracle Spatial depuis moins de deux ans. Les tests sont menés sur la version 2.2 et 2.4 de QGis. Ils permettront de vérifier si QGis est un bon candidat comme progiciel SIG, de le comparer avec d'autres logiciels comme MapInfo et de voir s'il est possible de concilier le stockage de données en entrepôt et l'utilisation au quotidien d'un SIG au sein d'une collectivité territoriale.

Ce projet qui m'a occupé pendant plus d'un an et demi avait pour objet de rationnaliser une infrastructure de sauvegarde basée sur deux outils différents. Le choix s'est porté sur une longue étape de conceptualisation et d'expression de besoins et de performances avant de déterminer une solution simple et robuste. Ce projet m'a permis d'étudier les concepts avancés de sauvegarde comme la déduplication, la minimisation des flux de réplication ainsi que l'intégration d'un système de sauvegarde dans un datacenter complet, y compris du point de vue sécurité et cloisonnement réseau.

La solution retenue s'est fixée autour de Symantec Netbackup. J'ai audité un grand nombre de logiciels libres de sauvegarde avant de conclure que même si certains avaient un potentiel intéressant, aucune solution libre (même basée sur plusieurs briques indépendantes) ne pouvait rivaliser avec les fonctionnalités attendues par la nouvelle plate-forme de sauvegarde. J'ai donc du me mettre à NetBackup et j'ai suivi la formation d'administration tout en conduisant une intégration de cet outil dans notre datacenter.

Projet de longue haleine que je n'ai pas pu terminer avant de rejoindre Nantes Métropole…

Mise en place d'un script unique pour simplifier l'administration d'un système de sauvegarde OpenSave. Passage d'un processus à forte intervention humaine (>4h ETP par jour) à une interention légère (<1h) et à vérification automatisée. Opensave est un vieil outil de sauvegarde mais quand on n'a pas le choix, il faut faire avec. Par ailleurs, il s'interface finalement assez bien avec de bons scripts shells. Le script réalisé pour faire toute l'administration (contrôle du bon déroulement des sauvegardes, relance des sauvegardes manquées, gestion des logs, gestion des duplications de bandes à bandes selon la politique interne) est réalisé dans l'esprit git: un seul script à gérer avec plusieurs sous-commandes.

Lors de ces réunions, il est très pertinent, au moment des discussions, que chacun des participants visualise directement les impacts de telle ou telle proposition. Un outil SIG permet de maintenir cette dynamique de réunion de manière assez simple:

• affichage des plans.
• modifications en temps réel.
• colorisation des bureaux par un code couleur donné afin de mieux délimiter les emprises de services.
• par une simple requête Spatialite, de faire le bilan chiffré des tests de placement (nombre d'agents, surfaces, statistiques basiques.
• de diffuser les plans au format PDF pour communiquer vers les agents dès la fin de la réunion.

Ce projet consiste à concentrer les données de la structure pour produire des fiches de synthèse contenant des tableaux et des diagrammes qui répondent rapidement aux questions métiers des services internes et des partenaires externes.

Ce projet met en oeuvre le logiciel libre BIRT qui permet de produire des rapports. Ces rapports constituent les fiches de synthèse que nous devons produire de manière massive: il en faut une par commune pour l'ensemble du département. La difficulté technique du travail consiste donc à élaborer un modèle de rapport avec BIRT et de construire un ensemble de tables contenant les données dans un SGBD (pas forcément relationnel). Cet ensemble de tables peut se voir comme un infocentre mais avec des besoins beaucoup plus faibles que ce terme peut laisser supposer. En effet, ce qui prime c'est la production du rapport et non la bonne organisation et l'exhaustivité des données métier.

Les règles de construction sont donc plus orientées vers la production que vers la définition et l'organisation: on part du principe que lorsque les fiches couvriront l'ensemble des données métiers de la structure, l'infocentre sera complet. De plus, la définition de la structure des tables dépend fortement de ce qu'on souhaite représenter.

Dans ce projet, le plus gros du travail est constitué par la définition des rapports avec BIRT. Il faut passer beaucoup de temps sur la mise en forme et sur la meilleure manière de représenter une information en adéquation avec les besoins du plus grand nombre. Cela passe assez souvent par une présentation sous forme de diagramme.

En ce qui concerne l'animation et la définition des besoins, nous avons travaillé avec une méthode Agile: le cahier des charges était assez flou au départ car les services ne savent que progressivement ce qu'ils désirent voir s'afficher sur leur fiche de synthèse. Il faut donc leur proposer une élaboration progressive tout en étant très dynamique sur les changements que ces interlocuteurs désirent voir.

Au final, ce projet s'étale sur deux ans et il est parfaitement exportable dans toute structure qui désire produire massivement une information de synthèse à moindre coût.

Les administrations utilisent très souvent des applications gérées par un niveau national en ce qui concerne les procédures de télédéclarations (déclaration de revenus pour les impôts, télédéclaration PAC). Toutefois, il existe des procédures qui ne s'appliquent qu'à un nombre restreint de départements et pour lesquelles le niveau national n'offre pas de solution.

Un constat assez simple montre que dans la plupart des cas, pour tenir compte de ces procédures locales, l'administration adresse un formulaire dédié au format papier aux citoyens concernés. Si on souhaite étendre les procédures dématérialisées, il est important de pouvoir proposer aux citoyens de tout télédéclarer, y compris pour ces procédures locales.

Ce projet rejoint cet objectif en s'appuyant sur une plateforme nationale de questionnaires en ligne qui s'appuie sur le logiciel libre Limesurvey, un logiciel de questionnaires en ligne. L'idée initiale part du principe qu'un formulaire administratif est, dans la majorité des cas, un questionnaire: on demande des informations aux citoyens dans l'objectif de voir s'ils sont éligibles aux critères retenus pour la procédure. D'où l'idée de détourner ce logiciel pour se recentrer vers la dématérialisation de certaines procédures.

L'intérêt de Limesurvey c'est sa simplicité: pas besoin de développer une application: tout se fait par paramétrage de questions et il est également possible de mettre un minimum d'intelligence (genre: afficher la question suivante uniquement si la réponse est supérieure à 150). Pas besoin de développeur, un simple webmaster suffit ! De plus, un deuxième intérêt est la possibilité de mutualiser fortement la production de formulaire: on peut importer un formulaire que quelqu'un d'autre à élaboré. On peut imaginer ainsi une répartition des charges au sein de plusieurs départements qui choisissent de se répartir le travail.

Enfin, Limesurvey permet de réaliser des exports dans des formats bureautiques (typiquement, fichier de tableur) qui sont facilement gérables par des agents non experts en système d'information.

Dans ce projet, nous avons élaboré 3 formulaires qui sont actifs et utilisés depuis quelques années. Le frein le plus important est l'absence de système d'authentification: les citoyens concernés remplissent toujours les mêmes questions sur l'identification (alors que nous disposons de toutes les données en interne). Sur ce dernier point, la seule solution ne peut venir que de l'administration centrale…

Le logiciel libre SIG QGis connaît un fort engouement ces dernières années. Ses fonctionnalités ont bien évoluées et il y a peu de travaux géographiques qu'on ne peut réaliser avec.

L'objectif de ce projet était d'expérimenter un dispositif de saisie des permis éoliens avec QGis. L'intérêt de cette solution est d'éviter de recourrir au développement d'une application web qui implique, même pour des choses aussi basiques que de la consultation de cartes, de développer une interface (en Javascript par exemple), de mettre en place un site web centralisé, de gérer les authentifications, etc.

Dans ce projet, QGis a montré un énorme potentiel dans la possibilité d'élaborer des formulaires intelligents sans aucune ligne de code ! On peut ainsi, avec un simple paramétrage dans un fichier de projet (.qgs) offrir un élément de saisie qui réduira les erreurs. De plus, cette expérience a également montré que QGis s'accomode très bien des modèles relationnels avec la possibilité de lier plusieurs tables différentes pour afficher des éléments dans le formulaire de saisie (typiquement des tables de paramétrage).

L'utilisation d'une base de données centralisée sous PostgreSQL/PostGIS permet de gérer à la fois les accès concurrentiels, l'authentification et également le rendu final des données. La mise en place de triggers géographiques permet enfin, de minimiser l'effort de saisie en appliquant à la volée certains traitements automatiques.

Ces fonctionnalités sont présentes dans la version 1.9.90 de Qgis et seront opérationnelles dans la version 2.0.

QGis est de plus en plus adopté par les services métiers mais il faut jouer le jeu du logiciel libre: lorsqu'on constate un problème il est d'abord indispensable de le faire remonter. C'est un travail que j'effectue ponctuellement lorsque je suis dans une impasse et après l'avoir partagé avec d'autres utilisateurs.

Parfois, je suis en capacité de régler le problème par moi-même et je publie quelques patchs qui sont le plus souvent intégrés par l'équipe de développement. Cette publication de patch se fait dans le cadre de mon activité professionnelle car elle est tout à fait en phase avec nos besoins et nos attentes et, la plupart du temps, elle ne prend pas beaucoup de temps (5 jours de travail par an en moyenne).

Lors de la fusion entre DDAF et DDE, les patrimoines de données des deux structures ont dû être mis en commun, de manière à n'obtenir qu'un seul infocentre géographique commun à tous les utilisateurs.

Ce travail fastidieux et complexe a permis de redéfinir les contenus de chaque donnée et de voir quelle était sa structuration. Après un inventaire complet, nous avons réussi à faire en sorte d'obtenir un seul infocentre géographique pour toute la structure en quelques années. Tout agent peut donc attaquer toutes les données publiées par ses collègues ce qui renforce l'aspect globalisant de l'information géographique dans les métiers.

Au delà du travail de vérification technique, la difficulté de ce projet repose essentiellement sur la mise en place d'une vraie démarche d'action sur les éléments sociaux de la structure via de la communication et des sessions d'information: le plus difficile fût d'amener un vrai changement de mode de travail et une véritable reconnaissance de l'intérêt de la centralisation. Un vrai travail de socialisation inter-services.

Il s'agissait de vérifier, par la pratique, si le logiciel QGis avait sa place dans le panel de logiciels SIG des ministères en charge du développement durable et de l'agriculture.

La démarche a impliqué des agents métiers (plutôt néophytes en SIG) et des agents géomaticiens utilisateurs de MapInfo. Après avoir choisi des sujets concrets à mettre en oeuvre, chaque personne de l'expérimentation a été formée à la version 1.5 de QGis (celle de l'époque) dans l'objectif de produire un document final exclusivement à l'aide de ce logiciel.

Le résultat montre que dans près de 90% des cas, QGis n'est pas bloquant et peut très bien faire le travail de MapInfo. Toutefois, pour le reste, quelques blocages apparaissent ainsi qu'une perte de productivité sur certains travaux bien précis. Néanmoins, l'issue de l'expérimentation me semble très positive: QGis évolue sans cesse et devrait, dans les prochaines années, corriger l'intégralité de ces points.

Il s'agissait d'élaborer une charte graphique pour toutes les cartographies de la structure de manière à ce que chacun puisse facilement repérer l'origine du document. L'intérêt d'une charte graphique commune est de donner un élément d'identité fort à la structure. Cela permet également de simplifier le travail de mise en page.

Là encore, l'enjeu du projet est repose davantage sur les aspects sociaux de la démarche plus que sur le côté technique.

Une des grandes difficultés quand on travaille en service déconcentré c'est de travailler avec les données métier des applications nationales. En effet, en raison de tout un tas de facteurs qui vont du manque de budget aux problèmes de gouvernance et de recueil des besoins, les applications nationales ne diffusent que trop peu d'informations.

Cela pose plusieurs problèmes tant du point de vue de la valorisation des données que du simple contrôles massif. C'est pour pallier à ce genre de problèmes courants que j'ai développé un script (en Python) permettant de récupérer des données géographiques (et attributaires) directement en utilisant l'interface Web d'un logiciel métier national et centralisé (le webscrapping).

Ce logiciel est efficace depuis près de 3 ans et il vaut largement son temps de développement ainsi que sa maintenance qui se limite à gérer les changements (peu fréquents) de l'application nationale.

L'objectif de ce projet consiste à réduire une phase de saisie dans une application métier qui met en oeuvre de l'information géographique. Sur ce sujet métier qui relève de la forêt, la gestion des dossiers est partagée entre deux services instructeurs différents. Un des services a fait l'effort de réaliser la saisie géographique des dossiers.

Le projet consistait donc à reprendre ces informations pour les intégrer dans notre logiciel de saisie. L'inconvénient majeur était situé à l'absence d'identifiants communs. Il a fallu recouper les données en utilisant un ensemble de requêtes géographiques (sous PostGIS) et en croisant avec le cadastre afin de déterminer le plus automatiquement possible les dossiers par rapport à leur géométrie.

Étant parfois cadre de permanence la semaine, j'ai eu l'idée de mettre au point une extension QGis pour faciliter le travail de réponses aux questions lors d'une crise. Dans ces conditions de stress particulier, la personne en responsabilité se trouve rassurée par la présence d'un outil simple à maîtriser qui lui permettra de répondre à des questions du genre: quels sont les cours d'eaux dans un rayon de x km autour de ce carrefour ? Combien de personnes se trouvent dans un périmètre de X km autour de ce point ? etc.

L'extension simplifie à l'extrème l'interface de Qgis pour n'offrir que les outils utiles. Elle concentre également toutes les informations du SIG en mode déconnecté et permet de produire des fichiers CSV contenant les informations essentielles.

Ce projet avait un objectif simple: faciliter l'accès au patrimoine d'information géographique via Qgis. Lorsqu'on utilise près de 300 couches différentes, on passe un temps non négligeable à se balader dans l'arborescence pour simplement ouvrir ce qu'on cherche. Sous QGis, c'est assez fastidieux (ouvrir une couche stockée dans un fichier implique l'ouverture de deux boîtes de dialogue différentes donc 4 clics au minimum).

Ce plugin modifie donc l'interface de QGis pour présenter un ou plusieurs menus supplémentaires qui déroulent l'arborescence des couches géographiques en précisant le type d'information (polygones/lignes/points) ainsi qu'une courte description de chaque couche. L'ouverture d'une couche se fait maintenant en un seul clic et les utilisateurs ont aun accès direct et immédiat à l'arborescence des fichiers.

Il s'agissait de produire une carte détaillée par commune et de leur faire parvenir par email. Travaillant sur tout un département, il fallait produire 363 cartes et envoyer autant d'emails personnalisés. A l'aide d'outils aussi simple que des scripts shell, nous avons automatisé tout le processus pour minimiser la durée du travail.

Basculer d'une suite bureautique à une autre n'est pas techniquement complexe. C'est bien le reste qui est plus difficile à appréhender. Ce projet fut l'occasion d'organiser des formations adéquates ainsi que de travailler sur de l'advocacy avec force communication à tous les niveaux et position aux petits soins (à l'écoute) de toutes les tracasseries des utilisateurs.

Lorsqu'on conduit une équipe informatique qui fait plein de choses, la tendance est à la spécialisation des individus. C'est encore plus vrai lorsqu'on travaille dans une petite équipe. Pourtant, la technique ainsi que la gestion de l'équipe impose que chacun dispose du minimum vital technique pour, ne serait-ce-que permettre à tout le monde de partir en congés !

Ce projet fut l'occasion de concentrer de la manière la plus accessible possible toutes les procédures, les méthodes et la documentation d'intervention pour toute l'équipe. Concrètement, la base documentaire a pris la forme d'un Wiki permettant à chacun de prendre la responsabilité de rédiger sa partie. Quelques formations et exercices nous ont permis de mettre en pratique toutes ces procédures.

Ce projet fait partie d'un effort de rationnalisation du parc de serveurs de la DDAF de Maine-et-Loire. Il s'agissait de concentrer les fichiers des agents sur une seule machine disposant de la bonne capacité disque plutôt que de devoir naviguer d'un serveur à l'autre suivant ses besoins.

Après l'effort de recherche, les machines sont mises en production et conduisent à vraiment simplifier le processus de gestion des fichiers pour les agents: un seul serveur est à utiliser et sa configuration est d'ailleurs transparente et automatique. La centralisation de l'authenfication par l'utilisation d'un annuaire LDAP permet à l'équipe de faciliter la création de comptes et de déporter les comptes pour d'autres applications: les utilisateurs se servent donc uniquement de leur comptes bureautique pour accéder à un maximum d'applications internes.

D'un point de vue technologique, ce projet (qui date de 2006), repose sur DRBD pour la partie mémoire de masse et sur Heartbeat pour la partie de contrôle de la haute disponibilité.

Un de mes premiers projets: de l'assurance qualité principalement.

L'objectif de ce projet était de dédier une machine à la sécurité. Ce serveur monitorait l'ensemble des machines de la structure ainsi que le réseau local et ses équipements. De plus il concentrait toute l'information des journaux systèmes pour faciliter leur exploitation.

Une des tâches les plus pénibles d'une équipe informatique consiste à déployer des ordinateurs de bureaux avec les applications nécéssaires par les utilisateurs finaux. On peut y passer des heures car l'installation d'un système d'exploitation n'est pas forcément une tâche rapide. Des solutions propriétaires existent mais je souhaitais davatange de souplesse et de maintenabilité.

Après quelques expérimentation, le projet a été séparé en deux entités liées:

• l'installation du système d'exploitation via le logiciel Unattended (et sa customisation interne).
• le déploiement distant des applications via wpkg.

Après avoir passé un peu de temps sur la configuration réseau, le temps d'installation total (de la réception de la machine à la livraison à l'utilisateur) est passé d'environ 4h à 10 minutes de travail effectif qui consiste à enregistrer la machine dans l'annuaire LDAP et lancer la procédure d'installation par PXE).

A noter qu'à l'époque (2006-2007), puppet/gpli étaient peu développés.

Disparition des imprimantes personnelles et remplacement par des machines réseaux+rationalisation de la logistique. Ce projet a permis de rationnaliser le parc d'impression dans l'objectif principal de réduire les coûts et de faciliter la gestion des consommables. Nous sommes passés d'un parc d'imprimantes jet d'encre individuelles à une large amjorité de machines réseau laser de bonne qualité. Le temps d'intervention et de logisitique a été fortement réduit.

Ce projet a permis également de centraliser la chaîne d'impression (via CUPS) afin de disposer de statistiques d'impression. La grande difficulté fut le côté "gestion du changement" au sein des services de la structure qui fut réglé en ayant l'appui de la direction, en parlant avec les utilisateurs et en acquérant des machines bien plus rapides et fonctionnelles (recto/verso, multibacs/multiformats/impression sécurisée/scanner).

Ce projet expérimental m'a permis de mesurer que la mise en place d'un système de tickets est voué à l'échec dans une structure à dimension humaine (100 personnes): le temps passé pour faire de la propagande auprès des agents est sans commune mesure avec l'intérêt de tracer les problèmes et les interventions. De plus, le logiciel mettait plus de distance entre les utilisateurs et l'équipe informatique ce qui ne fut pas bien perçu par les deux parties.

Et puis, l'ajout de procédures administrative dans une administration publique déjà saturée de procédures n'est certainement pas une bonne chose. Donc, quand on peut se le permettre, il est bon (stratégiquement aussi) de garder un bon lien de proximité entre la technique et les utilisateurs finaux.

Techniquement, le projet se base sur du Wake-On-Lan et des scripts shell. Un moyen simple de réduire sa facture électrique (importante dans une administration dont l'outil principal est un parc informatique).

L'objectif était de pouvoir utiliser des données issues de la DGFIP. A l'époque, ces données nous étaient utiles de maniètre très ponctuelle et je ne voyais pas vraiment l'intérêt d'acheter un logiciel dédié (de l'ordre de 1000€). Ayant eu l'opportunité de récupérer la norme AFNOR sur le format EDIGEO, j'ai pu "mettre les mains dans le cambouis" du format et construire un script de conversion en Perl. Ce script est disponible ici.

Ce projet s'est étalé sur près d'une année. L'objectif était de monter une application Web facilement maintenable pour gérer les procédures loi sur l'eau entre plusieurs structures (DDAF/DDE/Pref/DIREN). Après avoir obtenu les crédits nécéssaires, nous avons travaillé avec des partenaires externes pour finaliser la rédaction du cahier des charges et pour le développement.

Techniquement, l'application fonctionne en PHP et utilise une base de données fortement relationnelle sous PostgreSQL. J'ai réalisé la partie analyse des besoins, la recette et la maintenance applicative. Aujourd'hui, (plus de 5 ans après son lancement), l'application est encore utilisée et a su s'adapter aux évolutions réglementaires.

Étant compétent sous GNU/Linux, j'ai animé quelques formations sur ce nouveau (dans le contexte de l'administration française de la moitié des années 2000) à de nombreuses personnes. Nous avons abordé, souvent sur deux jours, les bases de l'administration système Unix. Le TP final consistait à faire quelques travaux avec VIM…

Le projet se basait essentiellement sur de l'information aux agents car il est bien connu que le premier problème en SSI, c'est l'interface chaise-clavier !

Excellente formation de base sur la sécurité informatique, prodiguée par l'ANSSI. J'ai beaucoup appris au niveau technique avec du personnel qualifié.