PROJET AUTOBLOG


Le Blog de Genma

source: Le Blog de Genma

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Comment j ai fait du social engineering... inconsciemment

jeudi 1 janvier 1970 à 01:00

L'ingénierie sociale

L'ingénierie sociale ("social engineering") est une technique qui vise à accéder à des informations confidentielles ou à certains actifs par la manipulation de personnes qui y ont accès directement ou indirectement. Le « phishing » (hameçonage) est un exemple d'ingénierie sociale.

Je ne m'attarderai pas plus sur le concept, on trouve des tas d'informations sur le sujet et quand on est à minima sensibilisé à la sécurité en informatique, le concept d'ingénierie sociale est quelque chose que l'on connaît. Dans le présent billet je voudrais relater une aventure que j'ai eu dans laquelle j'ai, comme le dit le titre de ce billet de blog, fait du social engineering... inconsciemment.

Mon anecdote

Dans le cadre de mon travail, j'avais besoin d'un accès à une plateforme particulière. Fin de journée, journée difficile. La seule personne qui a le compte d'accès est partie et est dans les transports en commun. Je l'appelle. La personne estime que la création d'un compte pour moi peut attendre son arrivée chez elle d'ici une heure, quand elle aura accès à un ordinateur.

Journée difficile pour moi, j'ai un stress communicatif et je mets donc la personne en situation de stress. Elle insiste sur le fait que cela puisse attendre ; j'insiste sur l'urgence et la nécessité de pouvoir me connecter. Je demande son identifiant et mot de passe pour pouvoir me connecter et faire la manipulation de création de compte.... La personne a fini par m'envoyer dans l'urgence via un canal sécurisé (un sms via Silence avec action du chiffrement) son identifiant et mot de passe. J'ai pu accéder au site web, m'ajouter un compte administrateur (avec un mot de passe issu de Keepass).

Le lendemain, j'ai fait une sensibilisation à l'hygiène numérique au collaborateur. En effet, étant désormais en possession de son mot de passe, même si elle peut avoir confiance en moi, cette confiance doit rester relative. Je l'ai donc inviter à changer son mot de passe et surtout à vérifier que le mot de passe donné était utilisé uniquement pour ce compte là et non un mot de passe générique que la personne utiliserait partout / pour tous ses comptes (règle d'hygiène numérique de base : avoir un coffre-fort numérique de mot de passe comme Keepaas).

En quoi est-ce de l'ingénierie sociale ? Et ce qu'il faut retenir de tout ça

Dans mon cas, le stress communicatif a fait que j'ai obtenu le mot de passe. Je ne l'ai pas fait volontairement, mais j'ai agi en utilisant une technique bien connue de l'ingénierie sociale : mettre la personne en situation de stress, avoir un ton direct et autoritaire, jouer sur l'autorité, l'urgence. Trouver le levier qui fait que la personne cède. On peut aller loin juste en parole : "tu ne veux pas que j'appelle ton supérieur qui alors va te faire des remontrances..." par exemple.

Cette expérience montre donc qu'il est très simple de faire de l'ingénierie sociale. Dans mon cas la personne me connaissait et j'avais une relation de hiérarchie indirecte sur elle. Mais si cela avait été un attaquant, sûr de lui, sachant pertinemment ce qu'il faisait avec un collaborateur ayant accès à des données plus sensibles ?

Nous avons eu une formation de sensibilisation à la sécurité. Je prévois de moi-même en faire d'autres. Nous avons et nous continuons sans cesse (dans le cadre de l'amélioration continue) améliorer notre politique de gestions des comptes et des mots de passe (je dois faire un billet dédié sur le sujet).

Mais on constate que malgré tout ça, il reste encore des services qui ont un seul accès maître détenu par une seule personne, ce qui est un point de fragilité, comme le montre mon histoire (quid d'une personne en congés etc...). Et que l'on a beau mettre en place toutes les mesures de sécurité que l'on veut, la faille de l'humain reste encore la plus facile à exploiter...

Il faut dès que possible favoriser une double authentification car dès lors que l'on a un identifiant et un mot de passe

Lifehacking - Gitlab, outil idéal ?

jeudi 1 janvier 1970 à 01:00

Depuis quelques années, je suis adepte du lifehacking et nombreux sont les articles que j'ai écrit sur le sujet. Des Todo j'en ai fait des tas, sur toutes les formes...Je suis familier de toutes les techniques organisationnelles projets comme les RIDA, RACI et autres... J'avais essayé de trouver un formalisme sous forme de tableau pour avoir un suivi des tâches, au sein de nombreuses itérations. Avec de nombreuses colonnes : projet, acteur, date de début, de fin, échéance, priorité, remarques... Mais quelque soit la mise en forme, la façon de faire (un onglet par projet ou autre), cela était toujours aussi peu flexible.

Gitlab

Au sein de mon entreprise, comme nous faisons du développement logiciel, nous avons une instance Gitlab auto-hébergée de la version communautaire. Parmi les fonctionnalités de Gitlab, au delà de l'aspect forge logicielle / hébergement de code, il y a différentes fonctionnalité que nous utilisons de plus en plus et ce pour chaque projet, dans le cadre de notre industrialisation. Dans le présent billet, je voudrais donc faire un retour d'expérience des différents outils.

Le Kanban

Le Kanban est probablement l'outil que j'utilise le plus. J'avais déjà fait des Kanban sur base de post-it dans une mission en AGIL dans une vie antérieure, j'avais un mur chez moi pour la gestion des mes projets personnels avec des post-it de différentes couleurs... Mais cela n'est pas pratique pour un partage, pour un travail à plusieurs et n'a pas de solution pour un usage en mobilité...

Les locaux actuels sont vitrés, les équipes avec lesquelles je travaille sont réparties au sein de différents services... J'ai besoin d'avoir une vision sur les différents projets et de pouvoir la partager.

La solution a donc été la généralisation de la mise en place d'un projet par service avec l'activation du Kanban pour chacun de ces projets. Et un Kanban pour les sous-projets. Je travaille encore avec une todo-liste que j'ai dans un bloc de papier dans lequel je note ma liste de choses à faire, que je raye au fur et à mesure de la journée. Toute tâche qui nécessite plus de détail, de suivi, d'être déléguée est si besoin rayée de la liste et mise dans le Kanban.

Avec le Kanban, j'ai un suivi des actions sur plusieurs jours ou plusieurs semaines, je suis sûr de ne rien oublier. En un ticket, j'ai un numéro de suivi si besoin, un acteur, je peux ajouter des dates. Et sur le ticket, je peux faire un suivi, commenter, ajouter des précisions, des liens vers le wiki et faire vivre l'action. Comme tout est électronique et au sein d'un navigateur web, c'est accessible, partageable. Les commentaires et le suivi sur un ticket sont cachés par défaut mais permettent d'avoir un suivi, de copier coller des échanges par mail, de mettre des liens vers d'autres tickets, des documents, des pages wiki... J'ai l'état d'avancement. Chacun peut commenter le ticket, ajoute des liens vers les pages wiki en cours de rédaction. On sait qui a quelle tâche. On voit l évolution. Il est possible de taguer un fichier avec plusieurs mots clefs chacun associés à une couleur. Il est possible pour chaque ticket de définir des dates de fin, un nombre de jours de réalisation, un "milletsone".

Dans les conseils que je donnerai il y a celui de prêter attention au nom des tickets qui doivent être autoporteur. Il ne doit pas être nécessaire d'ouvrir le fil du discussion du ticket mais il ne faut pas trop détailler non plus dans le titre. Un équilibre se trouve assez facilement au final.

Bref, j'ai trouvé dans le Kanban de Gitlab tout ce que j'avais cherché en essayant de structurer mes suivis d'action dans des fichiers avec colonnes...

En Kanban, j'avais auparavant testé l'usage de celui de Nextcloud (Deck) et celui de Kanboard. Mais celui de Gitlab, au delà de son intégration dans l'écosystème Gitlab, a de suite eu mon adhésion définitive. Un design plus moderne, plus riche, intégré avec tout un écosystème d'outils complet que je présente dans la suite de ce billet.

Le wiki

Pour chaque projet, Gitlab permet de créer un wiki dédié au projet. Chaque page est une page texte au format Markdown, qu'il est possible d'éditer au sein du navigateur même (avec une fonction de prévisualisation). Les fichiers étant des fichiers textes, ils sont suivis dans une branche dédiée par Git, avec toute la puissance niveau historisation que cela peut avoir.

Le wiki est récupérable en local en tant que projet Git, la bonne pratique est donc que chacun clone le wiki comme projet en local. Il n'y a pas de fork d'implémenter au sein même de Gitlab, on ne peut donc pas faire des forks et ensuite des branches etc. Tout le monde travaille donc sur un même dépôt qu'est le wiki ; cela nécessite donc de s'astreindre à certaines règles : mise à jour régulière du serveur vers le local et ce avant toute modification. Remontée rapidement sur le serveur les ajouts fait au wiki localement.

Pour l'édition, comme je le disais, le format est le format Markdown. On peut éditer au sein de l'interface web ou en local. C'est et ça reste du fichier texte. Nous avons mis en place un tutoriel utilisant l'éditeur Atom qui permet l'édition et la prévisualisation du Markdown (pratique pour avoir du WYSIYG) et un plugin Git pour pousser les modifications depuis Atom sur le serveur. Cela facilite la vie pour l'édition du wiki. Je pense que mettrai ce tutoriel en ligne sur ce blog pour le rendre accessible à tous.

La wikification : ce que j'appelle wikification c'est le fait de tracer dans le wiki toute information pertinente qu'il est nécessaire de garder, de conserver, au sein d'une base de connaissances. Nous généralisons, traçons, mettons à jour les procédures, les astuces etc. Tout ce que l'on peut attendre d'un wiki, nous le faisons au sein des wikis des différents projets de Gitlab.

Nous sommes d'ailleurs en train de reverser peu à peu les informations pertinentes en les mettant à jour d'un ancien wiki qui était sous Media Wiki dans le nouveau wiki. Un chantier long et fastidieux, mais nécessaire. L'ancien wiki était peu pratique, devenu lourd avec le temps, rédigé par des générations successives de collaborateurs sans suivi d'un formalisme particulier. Repartir sur une base saine et souvent le mieux à faire et nous le faisons.

L'espace fichier

Initialement prévu pour stocker du code source, nous utilisons cet espace pour stocker une arborescence définie de fichier. Avant il y avait un Intranet mais un simple partage de fichiers (nous n'avons pas de GED), mais avec le temps et l'accumulation des fichiers, c'est un peu devenu un fourre-tout inutilisable et inexploitable.

Nous utilisons donc pour chaque nouveau projet l'espace de fichier pour y stocker les fichiers de travail (fichier de configuration, documentation, procédures) dont nous avons besoin d'avoir une historisation, une centralisation et qui ne sont pas wikifiables.

Dans les pistes en cours d'étude il y a le fait que nous cherchons à pouvoir convertir des notes saisies en Markdown en documentation livrable au client, dans un format LibreOffice Writer avec un template de fichier défini (avec des codes couleurs précis). Un projet comme Pandoc pour la conversion avec ensuite application d'une feuille de style particulière sera à creuser.

Organisation des projets

Un service donne lieu à un projet, un projet donne lieu à un projet en lui-même dans Gitlab. Les pages wiki et la documentation sont mises au sein du projet pour lequel c'est le plus pertinent. Dans les autres wikis des autres projets, des liens sont fait vers les pages wiki et documentation de références. On utilise ainsi la puissance du web.

Pour faire un suivi à la hiérarchie, lors des réunions hebdomadaires, il suffit de présenter deux planches : une capture d'écran du Kanban prise en semaine N-1 et un une capture du Kanban de la semaine en cours. On peut alors visuellement voir l'avancement avec les tickets déplacés, les tickets en cours...

Bref, Gitlab est devenu un outil incontournable, efficace et indispensable pour moi.

Non intuitif pour les non informaticien.ne.s

Comme nous industrialisons nos projets, tout nouveau projet quel-qu'il soit est désormais créé dans Gitlab. Et le constat a été fait rapidement que dès que l'on sort d'une population purement d'informaticien, Gitlab nécessité des améliorations de son interface graphique pour pouvoir permettre une appropriation de l'outil en particulier dans la partie gestion des fichiers et suivi des modifications, qui restent avant tout pensé comme du "diff de code".

Et je ne suis pas seul à avoir saisi à la fois la puissance de Gitlab et le fait que ce n'est pas adapté aux non-informaticien.ne.s. En effet, dans le cadre de sa campagne Contributopia de Framasoft, dans la partie "Éducation populaire - Inspirer les possibles", il y a un projet Git à la portée de tou·te·s dont la description est la suivante : Git est un outil qui permet de collaborer collectivement sur du code. La manière dont il a été conçu ouvre une magnifique porte d'entrée vers les méthodes, pratiques et états d'esprits de la contribution. Comment faire pour que les personnes qui ne codent pas puissent profiter de la philosophie d'un tel outil ? Comment adapter git, son jargon, son interface, etc. afin que tout le monde puisse co-construire et collaborer sur des textes ou d'autres communs contributifs ? Des projets existent et c'est avec eux que Framasoft désire étudier des solutions.

Conclusion(s)

Au bout de quelques jours, Gitlab est devenu comme une révélation, un peu comme si je venais de trouver l'outil miracle. Nombreux sont les avantages que j'ai trouvé (me demandant même comment je faisais avant). Dans les autres avantages à avoir toute ma gestion au sein d'un même outil c'est que c'est pratique pour faire les sauvegardes.

Dans les autres petites choses que j'aimerai avoir et sur lesquelles il faut que je me penche, il y a celles d'avoir des métriques ou des statistiques en utilisant le temps de réalisation des tickets. Ce sera sûrement le sujet d'un autre billet, quand j'aurai pris le temps de me pencher sur ce sujet. Hop, c'est ajouté au backlog dans le kanban.

Lifechaking - Gitlab, outil idéal ?

jeudi 1 janvier 1970 à 01:00

Depuis quelques années, je suis adepte du lifehacking et nombreux sont les articles que j'ai écrit sur le sujet. Des Todo j'en ai fait des tas, sur toutes les formes...Je suis familier de toutes les techniques organisationnelles projets comme les RIDA, RACI et autres... J'avais essayé de trouver un formalisme sous forme de tableau pour avoir un suivi des tâches, au sein de nombreuses itérations. Avec de nombreuses colonnes : projet, acteur, date de début, de fin, échéance, priorité, remarques... Mais quelque soit la mise en forme, la façon de faire (un onglet par projet ou autre), cela était toujours aussi peu flexible.

Gitlab

Au sein de mon entreprise, comme nous faisons du développement logiciel, nous avons une instance Gitlab auto-hébergée de la version communautaire. Parmi les fonctionnalités de Gitlab, au delà de l'aspect forge logicielle / hébergement de code, il y a différentes fonctionnalité que nous utilisons de plus en plus et ce pour chaque projet, dans le cadre de notre industrialisation. Dans le présent billet, je voudrais donc faire un retour d'expérience des différents outils.

Le Kanban

Le Kanban est probablement l'outil que j'utilise le plus. J'avais déjà fait des Kanban sur base de post-it dans une mission en AGIL dans une vie antérieure, j'avais un mur chez moi pour la gestion des mes projets personnels avec des post-it de différentes couleurs... Mais cela n'est pas pratique pour un partage, pour un travail à plusieurs et n'a pas de solution pour un usage en mobilité...

Les locaux actuels sont vitrés, les équipes avec lesquelles je travaille sont réparties au sein de différents services... J'ai besoin d'avoir une vision sur les différents projets et de pouvoir la partager.

La solution a donc été la généralisation de la mise en place d'un projet par service avec l'activation du Kanban pour chacun de ces projets. Et un Kanban pour les sous-projets. Je travaille encore avec une todo-liste que j'ai dans un bloc de papier dans lequel je note ma liste de choses à faire, que je raye au fur et à mesure de la journée. Toute tâche qui nécessite plus de détail, de suivi, d'être déléguée est si besoin rayée de la liste et mise dans le Kanban.

Avec le Kanban, j'ai un suivi des actions sur plusieurs jours ou plusieurs semaines, je suis sûr de ne rien oublier. En un ticket, j'ai un numéro de suivi si besoin, un acteur, je peux ajouter des dates. Et sur le ticket, je peux faire un suivi, commenter, ajouter des précisions, des liens vers le wiki et faire vivre l'action. Comme tout est électronique et au sein d'un navigateur web, c'est accessible, partageable. Les commentaires et le suivi sur un ticket sont cachés par défaut mais permettent d'avoir un suivi, de copier coller des échanges par mail, de mettre des liens vers d'autres tickets, des documents, des pages wiki... J'ai l'état d'avancement. Chacun peut commenter le ticket, ajoute des liens vers les pages wiki en cours de rédaction. On sait qui a quelle tâche. On voit l évolution. Il est possible de taguer un fichier avec plusieurs mots clefs chacun associés à une couleur. Il est possible pour chaque ticket de définir des dates de fin, un nombre de jours de réalisation, un "milletsone".

Dans les conseils que je donnerai il y a celui de prêter attention au nom des tickets qui doivent être autoporteur. Il ne doit pas être nécessaire d'ouvrir le fil du discussion du ticket mais il ne faut pas trop détailler non plus dans le titre. Un équilibre se trouve assez facilement au final.

Bref, j'ai trouvé dans le Kanban de Gitlab tout ce que j'avais cherché en essayant de structurer mes suivis d'action dans des fichiers avec colonnes...

En Kanban, j'avais auparavant testé l'usage de celui de Nextcloud (Deck) et celui de Kanboard. Mais celui de Gitlab, au delà de son intégration dans l'écosystème Gitlab, a de suite eu mon adhésion définitive. Un design plus moderne, plus riche, intégré avec tout un écosystème d'outils complet que je présente dans la suite de ce billet.

Le wiki

Pour chaque projet, Gitlab permet de créer un wiki dédié au projet. Chaque page est une page texte au format Markdown, qu'il est possible d'éditer au sein du navigateur même (avec une fonction de prévisualisation). Les fichiers étant des fichiers textes, ils sont suivis dans une branche dédiée par Git, avec toute la puissance niveau historisation que cela peut avoir.

Le wiki est récupérable en local en tant que projet Git, la bonne pratique est donc que chacun clone le wiki comme projet en local. Il n'y a pas de fork d'implémenter au sein même de Gitlab, on ne peut donc pas faire des forks et ensuite des branches etc. Tout le monde travaille donc sur un même dépôt qu'est le wiki ; cela nécessite donc de s'astreindre à certaines règles : mise à jour régulière du serveur vers le local et ce avant toute modification. Remontée rapidement sur le serveur les ajouts fait au wiki localement.

Pour l'édition, comme je le disais, le format est le format Markdown. On peut éditer au sein de l'interface web ou en local. C'est et ça reste du fichier texte. Nous avons mis en place un tutoriel utilisant l'éditeur Atom qui permet l'édition et la prévisualisation du Markdown (pratique pour avoir du WYSIYG) et un plugin Git pour pousser les modifications depuis Atom sur le serveur. Cela facilite la vie pour l'édition du wiki. Je pense que mettrai ce tutoriel en ligne sur ce blog pour le rendre accessible à tous.

La wikification : ce que j'appelle wikification c'est le fait de tracer dans le wiki toute information pertinente qu'il est nécessaire de garder, de conserver, au sein d'une base de connaissances. Nous généralisons, traçons, mettons à jour les procédures, les astuces etc. Tout ce que l'on peut attendre d'un wiki, nous le faisons au sein des wikis des différents projets de Gitlab.

Nous sommes d'ailleurs en train de reverser peu à peu les informations pertinentes en les mettant à jour d'un ancien wiki qui était sous Media Wiki dans le nouveau wiki. Un chantier long et fastidieux, mais nécessaire. L'ancien wiki était peu pratique, devenu lourd avec le temps, rédigé par des générations successives de collaborateurs sans suivi d'un formalisme particulier. Repartir sur une base saine et souvent le mieux à faire et nous le faisons.

L'espace fichier

Initialement prévu pour stocker du code source, nous utilisons cet espace pour stocker une arborescence définie de fichier. Avant il y avait un Intranet mais un simple partage de fichiers (nous n'avons pas de GED), mais avec le temps et l'accumulation des fichiers, c'est un peu devenu un fourre-tout inutilisable et inexploitable.

Nous utilisons donc pour chaque nouveau projet l'espace de fichier pour y stocker les fichiers de travail (fichier de configuration, documentation, procédures) dont nous avons besoin d'avoir une historisation, une centralisation et qui ne sont pas wikifiables.

Dans les pistes en cours d'étude il y a le fait que nous cherchons à pouvoir convertir des notes saisies en Markdown en documentation livrable au client, dans un format LibreOffice Writer avec un template de fichier défini (avec des codes couleurs précis). Un projet comme Pandoc pour la conversion avec ensuite application d'une feuille de style particulière sera à creuser.

Organisation des projets

Un service donne lieu à un projet, un projet donne lieu à un projet en lui-même dans Gitlab. Les pages wiki et la documentation sont mises au sein du projet pour lequel c'est le plus pertinent. Dans les autres wikis des autres projets, des liens sont fait vers les pages wiki et documentation de références. On utilise ainsi la puissance du web.

Pour faire un suivi à la hiérarchie, lors des réunions hebdomadaires, il suffit de présenter deux planches : une capture d'écran du Kanban prise en semaine N-1 et un une capture du Kanban de la semaine en cours. On peut alors visuellement voir l'avancement avec les tickets déplacés, les tickets en cours...

Bref, Gitlab est devenu un outil incontournable, efficace et indispensable pour moi.

Non intuitif pour les non informaticien.ne.s

Comme nous industrialisons nos projets, tout nouveau projet quel-qu'il soit est désormais créé dans Gitlab. Et le constat a été fait rapidement que dès que l'on sort d'une population purement d'informaticien, Gitlab nécessité des améliorations de son interface graphique pour pouvoir permettre une appropriation de l'outil en particulier dans la partie gestion des fichiers et suivi des modifications, qui restent avant tout pensé comme du "diff de code".

Et je ne suis pas seul à avoir saisi à la fois la puissance de Gitlab et le fait que ce n'est pas adapté aux non-informaticien.ne.s. En effet, dans le cadre de sa campagne Contributopia de Framasoft, dans la partie "Éducation populaire - Inspirer les possibles", il y a un projet Git à la portée de tou·te·s dont la description est la suivante : Git est un outil qui permet de collaborer collectivement sur du code. La manière dont il a été conçu ouvre une magnifique porte d'entrée vers les méthodes, pratiques et états d'esprits de la contribution. Comment faire pour que les personnes qui ne codent pas puissent profiter de la philosophie d'un tel outil ? Comment adapter git, son jargon, son interface, etc. afin que tout le monde puisse co-construire et collaborer sur des textes ou d'autres communs contributifs ? Des projets existent et c'est avec eux que Framasoft désire étudier des solutions.

Conclusion(s)

Au bout de quelques jours, Gitlab est devenu comme une révélation, un peu comme si je venais de trouver l'outil miracle. Nombreux sont les avantages que j'ai trouvé (me demandant même comment je faisais avant). Dans les autres avantages à avoir toute ma gestion au sein d'un même outil c'est que c'est pratique pour faire les sauvegardes.

Dans les autres petites choses que j'aimerai avoir et sur lesquelles il faut que je me penche, il y a celles d'avoir des métriques ou des statistiques en utilisant le temps de réalisation des tickets. Ce sera sûrement le sujet d'un autre billet, quand j'aurai pris le temps de me pencher sur ce sujet. Hop, c'est ajouté au backlog dans le kanban.

Lucifer - la série

jeudi 1 janvier 1970 à 01:00

Synopsis

Fatigué d'être le « Seigneur des Enfers », Lucifer Morningstar abandonne son royaume et s'en va à Los Angeles où il est propriétaire d'une boîte de nuit appelée « Lux ». Lucifer a reçu le don de contraindre les gens à révéler leurs désirs les plus profonds. Un soir, Lucifer assiste au meurtre d'une chanteuse pop devant son club. Il décide donc d'aller à la recherche du coupable et croise sur son chemin une policière nommée Chloe Decker, qui résiste à son don et lui met des bâtons dans les roues. Pendant que Lucifer Morningstar et Chloe Decker font équipe pour trouver le meurtrier, Dieu envoie l'ange Amenadiel sur Terre pour convaincre Lucifer de régner à nouveau sur l'Enfer.

La critique de Genma

Découverte un peu par hasard sur conseil d'un couple d'ami, j'ai commencé à regarder la série Lucifer sur Netflix et j'ai accroché à tel point que je suis on ne peut plus à jour sur la diffusion de la série.

J'ai beaucoup aimé le personnage de Lucifer. Il a pour principe de ne jamais mentir. De fait quand il parle de sa condition d'ange, de son père, Dieu, de l'Enfer, tout le monde pense qu'il utilise des métaphores, qu'il se crée un personnage de part son prénom insolite... Le décalage et les quiproquo sont de fait nombreux et apporte de l'humour.

L'humour : il est présent régulièrement, avec des personnages intéressants, attachants, dont le background est développé épisode après épisode. Les personnages évoluent, changent, gagnent en profondeur et leurs relations évoluent. Et les rapprochements, la complicité augmentant avec le temps, l'humour est de plus en plus présent dans des remarques, des traits d'esprits. On n'est pas dans le mode "punch line à la Tony Stark comme dans un film de Marvel" mais plus dans des traits d'esprits. Et même de nombreuses références à la pop culture Geek : Lucifer est un geek, à n'en pas douter. J'ai ri jusqu'à plusieurs fois par épisodes.

Lucifer joue aussi de son charisme et de son charme, des nombreuses conquêtes qu'il cumule, de son personnage qu'il crée comme pour se protéger de la souffrance. Le tout sur fond de sa relation avec Chloe, mi amour, mi amie, cette ambiguïté permanente, lié à un fil rouge de la saison 2... Lucifer est un personnage complexe, qui évolue. Lucifer, de part sa condition d'être surnaturel, n'est pas à l'aise avec les comportements humains et les codes humains, il dit toujours la vérité. De fait, il heurte les sensibilités des gens mais quand il blesse les gens qui lui sont chers, il souffre. Il apprend à devenir humain, il devient humain. Et je me reconnais dans cette évolution, cette torture de vouloir bien faire et de faire souffrir des gens qu'on aime...

Le fil rouge des différentes saisons est sympathique et facile quand on a vu l'arc des anges de Supernatural (saison 7 et suivantes). Pas de complexité particulière et de volonté de faire un scénario tordue. C'est distrayant, plaisant. Mais efficace.

La musique... Que dire de la musique. Lucifer joue au piano et des parties de chansons et scènes sur fond de musiques sont mémorables. J'ai commencé à revoir des extraits en vidéo sur Youtube. Certaines sont des spoils donc à revoir uniquement quand on a va vue la série. Mais la scènes de reprise au piano de Sinnerman de Nina Simonne ou encore de Unforgiven de Metallica... Elles m'ont données et me donnent encore des frissons à chaque revisionnage.

Évolution et relation des personnages, les acteurs, les scénarios des épisodes, la musique... Définitivement j'adore cette série. Tout me plaît. A recommander.

Supergirl de Reamonn

jeudi 1 janvier 1970 à 01:00

A l'été 2000, comme tous les étés, je passais mes vacances en Pologne, dans un tout petit village dans un coin paumé. J'ai sympathisé avec un gars qui est venu passé quelques jours chez sa grand-mère et du coup, nous passons nos après-midi à discuter de tout et de rien, et surtout à regarder la télévision. Car la seule distraction, c'est la télévision par satellite avc un accès à différentes chaînes gratuites. Parmi ces chaînes, des chaînes allemandes et les chaînes musicales VIVA. Ayant appris l'Allemand en 1ère langue depuis le collège, en 2000, je comprends encore assez bien et je peux suivre une émission de télé sans soucis (j'ai beaucoup perdu depuis par manque de pratique). J'ai donc passé des après-midi entier à regarder des clips. L'une des deux chaines, VIVA 2, donne déjà dans le nostalgique avec des clips classiques des années 80.

Dans ces années là, les musiques et les hits du top 50 en Allemagne ne sont pas les mêmes que celles que l'on a en France, je découvre donc des nouveaux groupes, dont des groupes Allemand. Hit du moment, Supergirl de Reamonn passe en boucle plusieurs fois par jour. La page Wikipedia (uniquement en anglais) confirme que ce single n'a été diffusé que dans des pays de l'Est de l'Europe ou Germanophone (Suisse).

Quelques années plus tard, à l'heure de gloire de Kazaa et du modem 56k, j'ai pu retrouvé des fichiers au format mp3 du groupe (ouh le vilain pirate), avant de finir par trouver le CD en import dans une Fnac Parisienne. En 2017, fini le mP3, on est passé au streaming en vidéo avec Youtube et le clip de la chanson est disponible en ligne. Si vous souhaitez le voir, cliquer ici Reamonn - Supergirl (Official Video HQ) sur Youtube

Un clip d'époque, qui alterne des images du groupe en train de jouer et un mini-film qui raconte une sorte d'histoire. Comme beaucoup de clip de cette époque. Ca a sûrement vieilli, ce n'est pas Thriller de Mickael Jackson niveau réalisation, mais quand je le revois, je repense à cette époque, à mes souvenirs. Ca s'appelle de la nostalgie.

Du même groupe, deux autres chansons sorties en single "Star" et "Josephine", que j'écoute là encore avec nostalgie de la fin des années 90 et de mon adolescence...

Une autre fois, je vous parlerai peut être de ce groupe de rock gothic finlandais, à l'origine du Love Metal, HIM. Avec son symbole de l'Heartgram (un pentagramme en forme de coeur) et ses deux albums phare au titre évocateur "Greatest Lovesongs Vol. 666" et "Razorblade Romance".

I'm richer than you! infinity loop