Le 2 décembre dernier, j'avais 27 ans. S'en suit une petite fête en famille et ma soeur qui m'offre une station météo (en fait l'expression est un peu abusive, mais nous le verrons par la suite) censée être raccordée par USB à un PC. Ce qui est assez fantasque c'est que le terme "PC" implique encore trop souvent pour les constructeurs "quelquechose qui boote avec un drapeau en arrière plan et plein de fenêtres partout".
Bref, il a fallu un peu creuser afin de pouvoir intégrer l'outil au sein de mon appartement.
# · Lire toute l'histoire · Un commentaireSi vous avez suivi l'épisode précédent, vous savez que je m'intéresse (intéressais ?) à l'analyse décisionnelle (ou business intelligence, pour le terme anglophone). J'avais comme quête du graal de représenter les données d'openstreetmap par provenance, en étudiant le champ "source" utilisé parfois pour indiquer d'où proviennent les items géographiques.
En effet, les contributeurs OpenStreetMap ont la possibilité d'utiliser différentes sources afin de peupler la base de données libres de données géographiques. Parmi eux, des fournisseurs d'imageries aériennes (comme Bing Maps depuis que Steve Coast, un des fondateurs du projet, a négocié avec Microsoft un partenariat afin de permettre les contributeurs d'utiliser le fond d'images aérien pour ajouter des données, mais aussi plus anciennement Yahoo!), mais aussi le cadastre français, ou encore (sous certaines conditions) l'IGN, qui fournit une base de données de repères géodésiques, importée il y a quelques temps dans le projet.
En bref, pour reprendre l'histoire précédente, je voulais monter un entrepôt de données permettant de faire l'analyse sur la provenance ayant permis de tracer les différents items géographiques.
Afin de permettre de faire un import prenant en compte le tag "source" inclus dans les objets, j'ai là aussi utilisé osm2pgsql. Seulement, il m'a fallu un peu modifier l'application de base, car, osm2pgsql étant prévu pour faire du rendu (c'est d'ailleurs le rendu par défaut sur le site officiel du projet), celui-ci ignore le tag source, et ceci est "hardcodé" directement dans le code C de l'outil. Pour les curieux, vous trouverez en fin de billet le patch (trivial) permettant de prendre en compte ce détail.
L'import s'effectue comme d'habitude, modulo quelques heures étant donné la quantité de données non négligeable que notre pays connait, et nous nous retrouvons alors avec une base classique permettant le rendu, si ce n'est que nous avons une nouvelle colonne dans les tables planet_osm_point, planet_osm_line, planet_osm_roads, et planet_osm_polygon.
C'est à ce moment que le montage du cube prend place. J'ai dans un premier temps effectué quelques requêtes sur cette colone source, afin de savoir comment traiter des données, sur un tag qui ne suit aucune loi "logique" dans la façon dans laquelle il est renseigné. J'ai choisi donc de faire des requêtes du type "Je veux tous les éléments dont la colone source ressemble à Cadastre, ou BING ou Yahoo, sans distinction de majuscules et minuscules ...". J'ai ensuite modifié le script PHP que j'avais partagé précédemment, afin de permettre la transformation de ma base en une base utilisable pour faire les différentes analyses qui m'intéressaient. C'est aussi à ce moment que j'ai compris que cette étape ne s'effectuait pas du tout comme je le pensais. Une première tentative reprenait la précédente méthode, mais je me suis rendu compte que le temps de calcul était bien trop importante. Il m'aurait fallu environ 1 semaine et quelques jours pour y venir à bout.
J'ai donc cherché une autre méthode, pensant que c'était PHP qui était en tort, mais après une nuit passée sur une requête SQL monstrueuse, je ne me suis retrouvé qu'avec un peu plus de 200 000 objets en base. Ce qui était dommage, car encore moins efficace que la première approche, mixant du PHP et des requêtes SQL. Il a fallu alors checher une approche différente, et au troisième essai, je me suis retrouvé avec une méthode quasi-acceptable en terme de temps de calcul.
Cette méthode consistait à prendre la géométrie de chaque département, et de déterminer alors à l'aide d'une requête SQL l'appartenance géographique des objets en base suivant chaque géométrie. Il fallait compter 20 minutes, voire une demi-heure par département pour cela. Et comme j'en avais 92 à passer en revue, cela faisait tomber le temps de calcul à quelques jours (2 jours et quelques heures). Ce fut long, et je dois dire assez frustrant. Sur la quantité de données mises en jeu (une trentaine de gigaoctets), mon entrepôt de données tombait à un "dump SQL" ne pesant que 14 Mo une fois compressé en bzip2 au final. Tant de données à traiter, tant de temps passé à calculer, pour 14 pauvres mégaoctets ... Je trouve cela impressionnant, et me demande encore comment je pourrais optimiser afin de diminuer drastiquement ce temps de calcul.
Un autre problème sur lequel j'ai pu réfléchir était l'utilisation mémoire d'un script PHP rapidement (et sans doute mal) écrit. En effet, comme j'itérais sur tous mes départements en base, et que j'effectuais des insertions assez importantes, le processus en charge de l'insertion en base finissait par saturer la mémoire disponible sur la machine utilisée (qui dispose pourtant de 4 Go de mémoire RAM, et 10 Go de mémoire Swap). Contrairement à ce que je pensais au départ, il ne s'agissait pas d'une fuite au niveau de PHP mais d'une utilisation toujours plus importante de la session vers PostGreSQL qui était ouverte. Le moyen que j'ai trouvé pour contourner ce problème était de fermer la connexion à la base de données à chaque itération, et de la rouvrir.
Au final, vers 17h20 aujourd'hui, cette construction a fini par se terminer, et il était temps de tester ce nouveau cube.
Là encore, j'ai utilisé l'application développée dans le cadre de mon activité professionnelle, afin de voir ce qui ressortait de ce nouvel entrepôt de données.
Le résultat est graphiquement intéressant, mais aussi étonnant que cela puisse paraître, je trouvais que la chose la plus intéressante à apprécier suite à quelques requêtes multi-dimensionnelles simples, était le tableau donnant la source des données par portions administratives :
Voila, je ne sais pas si tout cela méritait un calcul de 3 jours, mais cela permet de se rendre compte de l'impact de l'autorisation d'utiliser le cadastre sur les autres systèmes mis à disposition. Et cela est sans doute aussi lié à la frénésie qui fait suite à l'import du bâti, et ce, quelque soit la région géographique considérée.
On remarque aussi (certes pas sur cette capture), que certaines régions jouissent d'un plus grand nombre de contributeurs que d'autres. Ainsi, apparemment, la région centre comptabilise environ un peu plus 965 000 objets géographiques, alors qu'on en compte plus de 1 866 000 rien qu'en Île-de-France.
Je suis un peu déçu du temps de génération de l'entrepôt de données, j'aurais bien aimé que cela ne prenne pas 3 jours. Mais au fond je n'ai pas eu vraiment le choix : le temps de calcul est évidemment proportionnel au nombre d'éléments qui finira dans la table des faits. Je n'avais pas le choix de prendre tous (ou presque) les éléments disponibles dans les différentes tables, et de calculer leur appartenance géographique à la plus petite entité de ma dimension géographique (au départ les communes, mais j'ai vite laissé tomber ce niveau pour me concentrer sur les départements, vu que de toutes façons mon application ne permet pas en l'état de présenter 23 000 éléments).
Ensuite, il ne faut pas oublier que OpenStreetMap contient des données assez "volatiles", pouvant changer à chaque minute. Ainsi, n'importe quel contributeur lambda détruisant l'intégrité d'une région pouvait être responsable de la disparition d'une région ou d'un département sur mon application. Peut-être que j'aurais pu etre un peu plus téméraire et réparer les limites administratives cassées avant de monter mon entrepôt. Ou alors me baser sur GeoFla (le produit de l'IGN, au format shapefile sur les limites administratives), qui est libre d'utilisation tant que cela reste dans un cadre non commercial. Je l'avais déjà utilisé par le passé, et la qualité du produit aurait amplement suffi dans mon expérimentation.
J'ai pu aussi me demander comment pouvait-on faire de la "BI" en temps réel ? C'est juste impossible dans mon cas. Je ne fait que récupérer les données de la base de données, je n'ai pas accès au système en production sur le projet. Sinon, on aurait pu imaginer des "triggers", qui mettent à jour les données du cube en temps réel à chaque modification effectuée par les contributeurs. C'est sans doute possible, mais techniquement je ne peux pas.
Je ne sais pas si c'est le fait d'être un peu fatigué ou autre, mais j'ai envie de passer à autre chose. J'ai vu ce que j'avais eu envie de voir sur l'analyse géodécisionnelle, cela m'a appris beaucoup, mais il y a tellement de domaines à creuser que je trouve que le temps passé sur celui-ci est échu. Il y aurait sans doute plein d'axes à creuser, notamment dans une potentielle participation au projet libre olap4j, ou même l'interface sur laquelle j'ai travaillé (et qui je l'espère sera open-sourcée un jour), voire d'utiliser des technologies autres que celles basées sur le langage Java, mais ce soir, j'ai envie de m'intéresser à autre chose.
- Le patch pour osm2pgsql
- L'entrepôt de données (dump SQL)
- Le nouveau cube XML
- Le générateur de l'entrepot de données ("should work", modifié après son exécution suite optimisations)
- Le journal de mes aventures, plus détaillé que ce billet, sur mes différentes réflexions
En avril 2010, un chef de projet dans mon entreprise actuelle arrive avec un sourire radieux :
"Tu vas voir, tu vas travailler sur un projet trèèèèèèèèèèèès intéressant !".
L'expérience m'a ainsi montré qu'il était important de se méfier des chefs de projets lorsqu'ils annoncent quelque chose de la sorte (comme on dit en latin, "Timeo danaos et dona ferentes") ;-) ; en effet, je me retrouvais propulsé sur un projet à base de Business Intelligence. Depuis, le projet a bien avancé, le client en est plutot content, mais j'avais l'impression frustrante d'être passé à coté de quelquechose : je n'avais acquis aucune connaissance dans le domaine, je me contentais pour résumer de coder des controlleurs qui renvoyaient du JSON et des graphiques sous forme d'image, et les données servant à alimenter le projet ont été construites par un prestataire canadien extérieur.
J'ai donc décidé d'en savoir un peu plus en montant mon propre "cube" (voir définitions du jargon technique plus loin) ; après tout, pour schématiser à outrance, la Business Intelligence (ou BI), c'est un peu l'étude efficace d'un gros tas de données, et il se trouve que les données d'OpenStreetMap, rien qu'en France représentent déjà un aspect de "gros tas de données" que l'on pourrait agencer pour des études spécifiques. Du moins, j'en avais l'intime conviction, sans trop savoir comment j'allais y arriver, je me suis donc lancé.
Voila, j'ai déjà commencé à dire des gros mots dans le paragraphe précédent et je m'en excuse, il faut donc repréciser quelques termes (de ce que j'ai pu comprendre) avant de pouvoir continuer mes explications :
- Cube : En Business Intelligence, on cherche à faire grosso-modo des statistiques sur des données, en les croisant d'une telle façon qu'une base de données classique ne permet pas (vraiment) de le faire. En effet, une table dans une base de données a une structure en deux dimensions (lignes / colones). Ici, on cherche à représenter des choses avec des données distinctes, et des dimensions supplémentaires. Cela parait un peu "fumeux", mais afin que vous compreniez, l'exemple le plus répandu se base sur les ventes de produits d'une chaine de grande surface (cherchez "foodmart" ou "geofoodmart" sur google pour plus d'informations). Une vente de produits peut en effet être rattaché (thématiquement) à diverses dimensions décrivant le type de produit, la "classe" du produit ou autres. Les solutions logicielles existantes continuent de stocker ces données dans une base de données classique, mais utilisent en sus un fichier de description en XML (en ce qui concerne la solution que l'on a utilisé dans le cadre de notre projet, on est parti sur GeoMondrian) permettant de faire le lien entre les différentes entités et "monter" cette représentation sous forme de cube (cube, car le nombre de dimensions est supérieur à deux, on sort du schéma classique "ligne / colone").
- Dimensions : Comme expliqué dans le point précédent, notre cube est composé de dimensions, permettant d'obtenir des informations plus précises sur ce que l'on souhaite analyser. Ces dimensions dans notre cas peuvent être de nature différente, thématiques ou spatiales. Cela est facilement imaginable dans notre exemple précédent, imaginez par exemple d'étudier les ventes de soda sur l'Ile-de-France uniquement, pour une période de temps donnée. Les dimensions sont décomposées sous forme de hiérarchies, elles-mêmes composées de différents niveaux (on peut par exemple avoir une dimension spatiale, auquel cas il est facile d'imaginer une hiérarchie dont les niveaux seraient communes / départements / régions, ou encore une dimension thématique plus "temporelle" avec une hiérarchie en mois / année, et une autre hiérarchie par mois / trimestre /année). Bref, le principe est de décomposer les données à analyser sous forme d'entités.
- Mesure : On peut considérer la mesure comme la pièce maitresse de notre cube. C'est, en gros, ce que l'on souhaite représenter. Ces informations sont stockées dans ce qu'on appelle une "table des faits".
- MDX : Une sorte de langage permettant d'effectuer des requêtes sur un cube ; c'est en 2 mots le "SQL de la BI".
- ETL : "Extract Transform and Load". Peut désigner un logiciel quelconque facilitant la mise en oeuvre de notre entrepôt de données (voir explications qui suit sur la structuration des données propres à une étude "BI"). J'ai toujours été rétissant aux clickodromes, et chez moi cette étape a été réalisée à l'aide de scripts PHP écrits à la main (ou bien dans le cas de mon premier cube, à l'aide d'un simple fichier SQL). J'ai ainsi le sentiment d'une meilleure appréciation de ce qui se passe vraiment à la construction.
- Table des faits : Table contenant les données que l'on souhaite ... "évaluer". Je n'ai malheureusement pas de définition plus précise à donner, tout du moins pour le moment. Pour reprendre l'exemple précédent, la vente d'un produit ira dans cette table. Chose toutefois notable : La table des faits contient tout le matériel de clés étrangères permettant de faire le lien avec les tables décrivant les différentes dimensions (je me suis basé sur cette assertion dans le cadre de mon projet personnel).
Cette structuration des données nécessite en général de repenser complètement son système de gestion de bases de données, afin de permettre un accès correct à l'information. Pour les adeptes des bases de données, on peut parler je pense de dénormalisation. Dans un schéma classique, il est évident que les données ne sont pas présentées comme attendu pour de l'analyse ; pour poursuivre l'exemple précédent, une chaine de grandes surfaces ne peut décemment pas stocker ses données dans un but d'analyse "BI" directement, sous peine de se faire trucider par le premier expert de base de données venu. Il faut donc monter un entrepôt de données (un datawarehouse dans la langue de shakespeare), indépendant du système "source", qui permettra ensuite l'analyse (les analyses) attendue.
J'ai utilisé l'outil incontournable de tout bidouilleur de données osm, Osm2Pgsql afin de charger les données francaises d'OpenStreetMap dans une base de données PostGreSQL / PostGis. Les habitués savent donc qu'on se retrouve ensuite avec des tables préfixées "planet_osm_*", selon le type d'objet géographique (planet_osm_point pour les points, planet_osm_polygon pour les polygones). D'autres tables sont créées, mais nous nous intéresserons pour le moment qu'à celles-ci.
La question évidente qui arrive suite à cela est la suivante "J'ai quelques gigaoctets de données en base maintenant, qu'est ce que je peux représenter avec ?".
J'ai donc recherché assez longuement sur cette question de "comment représenter quoi ?", mais en fait, en commençant d'abord par définir la structuration des tables définissant nos différentes dimensions, et en exprimant nos "mesures", on finit par imaginer le cube tel qu'il doit (devrait ?) être. Je reste volontairement hypothétique, car j'ai encore moi-même du mal à comprendre ce que j'avance. Finalement, j'ai opté pour la volonté de représenter ceci :
Un tag assez répandu sur OpenStreetMap est le tag "amenity". Ce dernier permet de géolocaliser sous forme de points ou de polygones un médecin, un bar, un hopital, une maison de retraite, un café, un distributeur automatique de billets ... On pourrait donc avoir un cube construit sur les limites administratives francaises donnant la densité de ce tag par emplacement géographique (communes, départements, régions). On distingue alors assez aisément les différents items :
- Dimension spatiale, avec une hiérarchie (communes, départements, régions). Pour des raisons de commodité, j'ai d'abord limité cette dimension / hiérarchie, sur un seul niveau : département.
- Dimension thématique : le type d'amenity (en langage OSM, la valeur du tag "amenity"). On y retrouvera donc "hospital", "bar", "cafe" ... J'ai là aussi limité aux tags dont la valeur apparaissait au moins dix fois en base (inutile par exemple de représenter les fautes d'orthographe des contributeurs).
- Mesure : Le décompte de ces "amenities", suivant les différentes entités définies dans les dimensions. En d'autre terme la densité.
Ce qui donne ainsi la table des faits ("la quête du graal" dans la construction d'un cube) suivante :
osm=# \d osmbi
Table « public.osmbi »
Colonne | Type | Modificateurs
-------------------+---------+---------------
departement_osmid | integer |
osm_amenity_id | integer |
count | integer |
Pour infos, ci-après la structuration des tables représentant les deux dimensions :
osm=# \d osmbi_amenity
Table « public.osmbi_amenity »
Colonne | Type | Modificateurs
--------------+------------------------+------------------------------------------------------------------------
amenity_id | integer | non NULL Par défaut, nextval('osmbi_amenity_amenity_id_seq'::regclass)
amenity_type | character varying(512) |
osm=# \d osmbi_departement Table « public.osmbi_departement » Colonne | Type | Modificateurs ---------+----------+--------------- osm_id | integer | name | text | way | geometry |
Nous avons à peu près tout. Je vous passe les détails sur la construction et le remplissage du cube, cela risquerait d'alourdir le billet inutilement. Pour les curieux, allez voir les liens en fin de billet.
Une fois l'étape d'extraction / chargement des données (voir la définition de ETL plus haut) dans ces tables effectuée, il ne restait plus qu'à rédiger notre fichier XML, qui sera lu par le logiciel GeoMondrian, et qui nous permettra de faire des requêtes MDX.
J'ai ensuite repompé sans vergogne le code de l'applicatif que nous avons développé pour notre client hispanique, et j'ai tenté de le brancher sur mon nouveau cube. Suite à quelques remaniements (il s'agissait d'un prototype, donc il n'était pas parfait, et quand bien même cela aurait été un projet pour une application "de production", il ne l'aurait sans doute pas été non plus), j'ai pu effectuer des requêtes du type "Je veux la proportion de bars, boites de nuit et cafés en Isère et en Savoie". Graphiquement, cela donne le résultat suivant :
Trouvant ce premier cube trop simpliste, je me suis lancé, cette fois-ci à grand renfort d'un script PHP (on dira ce que l'on voudra, mais lorsque je souhaite être expressif dans un langage et passer le moins de temps possible pour arriver à mes fins, il s'agit là encore mon langage de prédilection) dans la construction d'un nouveau cube, cette fois-ci contenant toutes les communes francaises disponibles en base, les départements (que j'avais déjà), et les régions. J'ai aussi ajouté une nouvelle dimension thématique décrivant le type d'objet spatial (qu'il s'agisse d'un point ou d'un polygône) dans OSM.
Malheureusement, au branchement de mon cube dans l'application, la sentence ne s'est pas faite attendre trop longtemps :
/webbi/getcubeproperties
java.lang.OutOfMemoryError: Java heap space
J'ai sans doute eu les yeux plus gros que le ventre. Mes prochaines expérimentations à prévoir la dessus sera d'oublier les 23 000 communes que j'ai en base pour le moment, pour me focaliser sur les quelques départements et régions disponibles. De toute facon, dans l'affirmative où cela serait passé, cela signifie que l'on se serait retrouvé dans son navigateur Web à avoir la possibilité de sélectionner des éléments parmi ces 23 000. Inutile d'espérer pouvoir le faire décemment, même dans le meilleur navigateur au monde.
Cela a été une investigation intéressante, et m'a donné pas mal de recul sur le sujet. C'est un peu dommage de ne pas avoir réfléchi à tout le domaine avant, mais peut-être était-il nécessaire d'attendre d'avoir un certain recul avant d'imaginer se lancer dans l'aventure. Je garde sous le coude un autre projet qui intéressera potentiellement des fournisseurs de données à OSM : Monter un cube sur le tag source des objets en base. Mais cela va demander une modification du code de Osm2pgsql, ce dernier étant prévu en effet pour le rendu, il ignore (et c'est "hardcodé") le tag source qui sera intéressant pour notre analyse.
- Le journal plus détaillé de ce périple, notant mes diverses "random thoughts"
- Les quelques requêtes permettant de monter le premier cube
Attention, certaines requêtes peuvent prendre quelques heures, et cela donne juste l'idée générale, n'espérez pas avoir un entrepôt de données correct juste en le jouant. Désolé, j'ai un peu perdu l'historique de la démarche de mon premier cube, lorsque je me suis mis à travailler sur une version 2.
Autre détail, je n'ai déontologiquement pas le droit de fournir le code de l'applicatif web ayant permis d'effectuer la capture d'écran présentée dans ce billet. Désolé pour cela. La solution étant toutefois basée sur GeoMondrian, vous devriez être en mesure de cabler le cube sur une interface Olap4J.
J'ai retravaillé un peu ma version 2 du cube, et j'ai compris certaines choses en terme de définition de cube telle qu'attendue par les outils utilisés. Quelques screenshots sont disponibles ici. Pour le coup, je crois que j'ai à peu près tous les éléments en main (même si ma connaissance du domaine me parait encore un peu trop sporadique en toute sincérité) pour monter des cubes de données sur tout et n'importe quoi. Mission accomplie !
Je dois être un peu insomniaque, et du coup, je fournis les sources pour monter la "version 2" de mon cube :
- Script PHP permettant de monter le cubev2 (Il met environ 3 heures à s'éxécuter, et si vous voulez "dénormaliser" (?) afin de se concentrer sur juste les niveaux départements et régions, n'oubliez pas de jouer les 2 dernières requetes SQL en commentaire dans la source.
- La définition du cube en XML
# · 4 commentairesL'histoire se passe entre Thiviers et Saint-Jean de Côle, en voiture avec ma soeur qui n'en peut presque plus de la route Grenoble / Quelque part perdu dans le Sud-Ouest, sur laquelle nous nous trouvons depuis 6 bonnes heures dans le but d'assister à un mariage de famille. Puis le portable sonne, mon père qui s'inquiète :
Papa : - Pierre ? Vous êtes où la ? il est 16h10, la cérémonie commence à 16h00 ; c'est bien à Saint-Jean-de-Côle hein ... Et n'oublie pas ton alto, je te rappelle que tu es censé jouer à la messe ...
Moi : - On est au courant, on vient de se changer avec Claire, on arrive d'ici 10 minutes, je suis au courant pour l'alto, et puis quand bien même je l'aurais oublié, on va pas faire demi tour pour aller le chercher à Grenoble ... Quant aux partitions, désolé, mais j'ai vraiment pas eu le temps de les travailler alors je vais un peu déchiffrer / réinventer Mozart pendant la messe si tu n'y vois pas d'inconvénient ... Non, la faute à mes tortionnaires de patrons, on dira (ndR : il fallait bien une excuse presque bidon) ... Mais sinon, t'es chiant : en me téléphonant, tu as encore fait bugger ma trace GPS, comment vais-je pouvoir faire avancer le monde des données géographiques libres ; tu as pensé aux conséquences de ton acte, hein ?
Papa : - .........
Bref, la morale de cette histoire est certainement que la vie est une question de priorités (ou tout simplement qu'il faut que j'investisse dans un vrai bon GPS datalogger). Pour la petite histoire, ayant eu des bons retours de mon déchiffrage altistique, j'ose imaginer que ca a plu. Ou alors j'étais peut-être entouré d'hypocrites ; la prochaine fois je tacherai de soigner tout de même un peu plus quand on me demandera de jouer de l'alto à une cérémonie, parce que la, cela faisait plus figurant que concertiste. Et les traces GPS, dans tout ça ? il faut encore que je jette un coup d'oeil; mais j'ai un import massif et breton sur le feu.
(PS : Oui, il ne se passe pas grand chose par ici, il m'arrive d'avoir envie de dépoussiérer, mais bon ; pour ceux qui se demandent ce que je deviens, ca va, je suis vivant, toujours Chambérien ; depuis la dernière fois - i.e. depuis le dernier billet -, pas grand chose de neuf, j'ai suspendu mon compte facebook en attente de mieux, donc si vous voulez me contacter, il faudra dorénavant choisir un autre moyen)
Bonne soirée !
# · Aucun commentaireJe sais, cela fait un moment que je n'ai pas écrit par ici. Sans vouloir me justifier auprès de mes potentiels lecteurs, sachez que c'est avant tout dû à un manque profond de motivation, de réflexions diverses sur le fait que je pouvais éventuellement perdre mon temps à rédiger tout ca, ou encore le droit à l'oubli et les traces que l'on peut laisser sur internet. Et puis au fond, au point où j'en suis, peut-être qu'un jour mon employeur me reprochera de trouver des photos de moi sur un réseau social bien connu, devant un gigantesque plat de gauffres et avec un sourire provocateur. Bien, de toutes façons, ce n'est pas de cela qu'il s'agit.
Tout d'abord, comme vous avez pu l'apprendre si vous me cotoyez ou si vous êtes lecteur assidu, oui, je n'habite plus Aix-en-Provence, et oui, tout va bien, le boulot tout ça, l'alto est en réparation, donc pour les loisirs musicaux, il va falloir patienter quelques jours. Ce n'est pas de tout cela non plus qu'il s'agit. Du moins, pas directement.
Mon nouveau boulot, comme j'avais eu l'occasion de l'expliquer à mes supérieurs, me plait dans le sens où l'on touche à un certain nombre de technologies - certes en rapport avec le web - mais il serait réducteur de penser que notre domaine d'activité se limite à la création de sites web, domaine d'activité de très nombreuses agences, et comme vous pouvez le constater par ici, je n'ai pas les talents d'artistes nécessaires pour justifier un emploi dans ce domaine. Le web-SIG réclame tout de même des compétences plus poussée que l'écriture de scripts PHP que l'on envoie sur un serveur FTP. Bref, la dessus, j'ai dû manger du python, du Java, et pléthore de langages divers et variés, et bien évidemment tout ce qui a trait au Web. Mais venons-en au byzutage qui a en quelque sorte joué le rôle de cadence parfaite de ma période d'essai.
J'ai en effet eu deux jours en début de semaine allouée à la mise en production (pas encore de lancement officiel) du projet sur lequel j'ai travaillé en majorité depuis mon arrivée. Et je me suis senti bien seul. Et c'était monstrueusement flippant. Dans l'idéal, on m'aurait donné l'administration d'un serveur tout neuf avec des noms de domaines pré-réglés pour configurer un serveur Web rapidement, modulo l'installation des différentes briques logicielles, tout aurait été réglé en une demi-journée voire moins. Mais non, c'eût été trop facile :-) Il a donc fallu traiter avec un serveur sur lequel tournait déjà 2 sites en production, et l'installation hâtive d'un python2.5 a complètement fait tomber l'un des sites. Indisponibilité pendant une nuit. Et j'en étais seul responsable. Je connaissais pourtant le système d'exploitation utilisé, j'avais pourtant pris le maximum de précautions. Et malgré cela, ... Bref, j'ai appris que le métier d'administrateur système était loin d'être aussi trivial que d'être un linuxien de tous les jours. Ca ne s'invente pas, il faut être un peu super-héros, ou James Bond des systèmes d'informations, mais au lieu de draguer des blondasses niaiseuses au service du KGB et conduire des Aston Martin, il nous faut avec nos seules mains et une bonne bobine de scotch numérique recoller les morceaux, avant que le client ne remarque quelquechose et ne déclenche une guerre nucléaire sous prétexte que l'on a joué à l'apprenti sorcier avec son serveur.
Donc après avoir passé une très mauvaise nuit, se réveiller à 4 heures du matin, ouvrir un oeil, et se dire "où j'en suis déjà ? ah oui, la nuit, pour le site du client que j'ai atomisé, on verra demain à tête reposée, cela ne sert à rien de stresser maintenant ...", avec l'aide de nos super-héros suisses (comprendre l'équipe de sysadmins), j'ai rapidement pu réparer et rétablir le service. S'en est suivi une journée à perdre une bataille contre des dépendances logicielles incompréhensibles, puis en rentrant dans le bus, j'ai eu une petite révélation. Arrivé chez moi, je me reconnecte, et en moins de 40 minutes, j'arrive à peu près à finaliser cette installation qui trainaît depuis trop longtemps.
Je passerai sur les aspects techniques (parce qu'on s'en fout au fond), mais finalement, même si j'ai "failli mourir" d'excès de stress, j'ai bien aimé cette expérience, cela m'a appris des choses - évidemment techniquement - sur la façon dont un administrateur peut avoir l'esprit tordu en terme de configuration serveur, mais aussi sur la maîtrise de soi, savoir relativiser sur les problêmes (au fond, tout le monde s'en foutait de son instance de django qui sert à répertorier des observations de feuilles qui tombent en automne, la preuve, l'indisponibilité est passée inaperçue), et puis j'ai signé "pour le meilleur et pour le pire" après tout.
Je me demande quelle sera la prochaine épreuve dans ce fort boyart professionnel, mais ce qu'il y a de sûr, c'est que je ne manquerai pas de l'aborder sous un angle différent dorénavant (en espérant que je serais moins trouillard et moins stressé que sur l'expérience dont il est question ici). Et puis au fond, le métier d'ingénieur, c'est savoir régler des problèmes (contrairement aux mauvaises langues qui diraient que ca consiste à tchatter sur gtalk à longueur de journée). Et je suis maintenant sûr d'une chose, je veux bien faire "un peu de sysadmin", mais jamais à temps plein.
# · 2 commentairesCela va bientôt faire un an que j'ai obtenu mon diplôme d'ingénieur, et un petit peu plus que j'ai commencé ma vie professionnelle à proprement parler. Donc c'est le moment d'être un peu nostalgique sans doute. Les gens "décalés" de ma promotion et ceux de la suivante vont donc bientôt recevoir à leur tour leur "bout de papier" attestant de leur capacité à intégrer le monde du travail.
Bref, cet instant visant à sceller les quelques années d'études passées à Belfort, je n'ai pas pu le vivre l'an dernier, non sans quelques regrets sans doute ; mais au fond, à quoi bon toute cette symbolique ? Est-ce que tout cela a un sens et nécessite de déployer des "vidéoprojecteurs 20 000 lumens Full HD" ? (non, cette information n'est pas tirée d'un de mes contacts facebook travaillant à la communication de mon école ; de surcroit, lorsque l'on apprend que la location de ces bestioles a couté 10 000 euros à l'école, je suis bien content que la force des choses m'ait poussé à ne pas cautionner ce genre d'initiatives l'an dernier, en séchant allégrement ma remise des diplomes pour cause de soucis ferroviaire ; je sais pas, ne pourrait-on pas "régler le problème de la faim dans le monde" en réinjectant les sous ailleurs ?). Est-ce réellement nécessaire toute cette mise en scène quasi-théatrale, petits fours et champagne, habillés en pingouins, et discours de grands pontes de la région Belfortaine opus 42 en crise économique dièse majeur ? Quoiqu'il en soit et en retrospective, j'ai bien aimé mon gala chaotique de l'an dernier. Heureusement que je pouvais compter sur vb, Bertrand et Barbu pour lui donner un sens inattendu ; mais plaisant, au vu du flou artistique mélant amertume et catastrophes avec lesquelles tout cela avait commencé.
Bertrand, tu me faisais remarquer à juste titre que je désertais un peu ce blog ; alors ce billet est pour toi, à défaut de venir au Congo t'organiser ta remise des diplômes entre deux bananiers de l'ambassade de France, tu as toute mes félicitations, pour les bons moments qu'on a pu passer en ta compagnie durant ces 5 ans et plus (et les bons moments à venir), je te donne même le mineur de la jovialité à l'unanimité ! (Et bien entendu, bravo à tous les autres diplomés cette année, cela va de soi, et amusez-vous bien).
# · Aucun commentaireIl y a pire que la crise financière, la grippe H1N1, ou autres fléaux de notre monde moderne ; il y a la folie furieuse dépensière du frangin. Ainsi, suite à une pulsion consumériste, nous avons finalement craqué avec Benoit, et nous avons fait chacun l'acquisition d'un Neo Freerunner (comprendre pour le non-geek un téléphone libre).
# · Lire toute l'histoire · 6 commentairesJ'ai hésité à appeler ce billet "Démission, mode d'emploi", mais n'étant probablement pas un maître en la matière et préférant cibler le thème sur mon futur changement radical de vie, je me contenterai d'un titre pour le moins geek, mais si représentatif de mon état d'esprit actuel et de mon intention de donner un "bon coup de barre vers Nord". (Billet très personnel, c'est là normalement tout l'intéret d'un blog, mais je préfère prévenir mes lecteurs que si vous n'avez pas de motivation pour le lire, je ne vous en voudrai pas).
Cela fait un petit moment qu'il ne se passe pas grand chose par ici ; et pour cause, j'étais assez occupé ces derniers temps à travailler à un changement de mon écosystème vital. Depuis deux mois, plus ou moins calme (pour cause de période de vacances, et accessoirement de recherche d'emploi), mon appartement a été plutot délaissé au profit de petits séjours dans un certain nombre de coins de l'hexagone, ou squatté par des amis. Et le retour à la réalité, "seul contre tous", fut assez douloureux. D'où le besoin de remédier à la situation actuelle.
Je viens donc de m'engager pour un travail bien plus intéressant comparé à ma situation actuelle, sur le plan de l'intéret professionel que je peux y porter, mais aussi vis à vis de son positionnement géographique. En effet, quitter Aix-en-Provence était un peu mon leitmotiv depuis ... presque le début. S'en suit la nécessité de "remercier" mes employeurs actuels.
Et c'est un peu là que tout se complique, la "confrontation finale" étant prévue pour demain ; en effet, il faudrait être un demeuré pour imaginer que l'on va me laisser partir sans explication à donner. Comment leur expliquer que là où la majorité de mes collègues estiment vivre dans un véritable paradis sur Terre, je n'y voies qu'un enfer climatique, et un Néant social et culturel ? Comment, sans réellement avoir déjà exposé le problème de mon désintéret pour ce que je fais depuis janvier dernier, leur expliquer que non content de subir un véritable suicide social, mon activité professionnelle ne me fournit aucune satisfaction intellectuelle ? Comment aborder tous ces sujets sans tomber dans une folie virulente et sanguinaire ? On appelle cela tout simplement un subtil mélange à base de diplomatie et de sang-froid, mais c'est pour l'instant basé sur une bonne insomnie, et un travail fastidieux des méninges.
Réjouissons-nous, j'ai déjà plus ou moins préparé le terrain et un certain nombre de mes collègues sont d'ores et déjà au courant (pour peu qu'ils tombent sur ce billet ...) ; surtout lorsque je parles de vacances en Bretagne à table et qu'un de mes supérieurs réagit - appréciez la fierté de l'Aixois de base - ainsi :
- En Bretagne ? J'espère que tu as pris des antidépresseurs, il pleut tout le temps la bas ...
La seule chose d'intelligible à lui répondre a alors été de ma part :
- Les antidépresseurs, je les garde pour Aix.
Bref, vous l'aurez compris, j'axerai mon débat demain (ou plutot aujourd'hui) sur le fait que la région ne me plait pas, et que l'orientation professionnelle non plus (voir billet précédent sur les geeks et les méthodes formelles). Mais en attendant, je ne suis pas sur de passer une bonne nuit, et qui plus est, je me retourne le cerveau dans tous les sens afin d'imaginer et d'anticiper les "coups de l'adversaire". Il me faudra donc un bouclier, une arme et une bonne paire de spartiates dans l'arêne pour sauver ma peau. Reste donc plus qu'à trouver en quoi correspondent ces différents items d'un point de vue métaphorique, et j'ai heureusement toute la nuit devant moi ...
Épisode 2 (ou, "la suite") : Malgré l'impression d'hier que certains me tiraient une tête un soupçon "endeuillée", il va vraiment falloir que j'évolue, et d'arréter de croire que le monde est sans cesse contre moi ; en effet, là où je pensais déclencher un "bain de sang émotionnel", je suis tombé sur des gens tout à faits compréhensifs et cherchant le dialogue, et le mieux pour les deux parties. Reste à voir si mon départ pourra être anticipé ou pas, la réponse d'ici la fin de la semaine. Mais dans tous les cas, cette aventure a été une bonne expérience, dans le sens où je pense avoir gagné des niveaux en gestion des relations sociales en milieu professionel. Pour finir avec une phrase bien "cliché", je dirais que c'est "une bonne école de la vie". A suivre.
# · 4 commentairesDepuis 1936 et Léon Blum, les salariés Français ont droit à des congés payés ; c'est complètement "bateau" de commencer un billet comme ça, j'en suis conscient et vous m'en excuserez, mais on aurait tort de ne pas en profiter. Bref, comme j'en avais un peu marre de la Provence et de son climat invivable, j'ai décidé de poser une petite semaine ; qui plus est, le boulot était calme depuis quelques jours. Pour l'instant cela commence avec l'achat d'un billet de train pour la Bretagne Sud avec du TGV + métro + TGV, pour un total d'environ 1400 km en quelques heures.
Sinon, en consultant mes mails à la gare (bien qu'à deux minutes de chez moi) via un hotspot de mon FAI, je me suis demandé pourquoi, avec le nombre d'abonnés Internet en France ayant des genres de set-top-box (Freebox ou autres) on ne pourrait pas imaginer mettre à profit ces dispositifs informatiques pour permettre d'avoir un genre de méga-application de calcul distribué ? C'est vrai, vu le nombre de services que ces boites sont succeptibles de proposer (téléphone, internet, télévision), elles doivent avoir "sous le capot" une puissance de calcul non négligeable (multiplié par le nombre d'abonnés), qui ne sert la plupart du temps à rien (quand l'abonné n'est pas chez lui, ou tout simplement en vacances). Et pourquoi on ne pourrait pas imaginer un accord entre fournisseurs d'accès pour avoir un service de connexion WiFi universel ? Tout le monde ne peut pas avoir un abonnement chez chacun d'entre eux pour se connecter de n'importe où. Dommage qu'on ne vive pas dans un monde de bisounours sans doute, ca pourrait etre utile ... :-)
Bref, je vous laisse, lecteurs arrivés ici par hasard ou les habitués, à ces réflexions qui ne mènent sans doute nulle part, et je vais commencer à savourer mes vacances par la préparation de mon sac. A bientot peut-être, quand le génome humain aura peut-être été décodé entièrement par Free ou ses concurrents.
# · 2 commentaires