Teddy Payet

SPIP en 2026 (2/2) : quand les projets échouent vraiment

Teddy Payet — 2026-01-02T08:00:00Z

Les projets SPIP ne basculent pas à cause du code, mais à cause de ce qui se joue autour. Derrière les architectures figées et les sites que plus personne n'ose faire évoluer, il y a toujours des choix humains, des rôles flous et des décisions différées.
Cette seconde partie s'intéresse à ce moment précis où l'outil devient le bouc émissaire, alors qu'il ne fait que révéler les fragilités d'une gouvernance, d'une organisation et d'un pilotage mis à l'épreuve du temps.

Introduction

Les difficultés d'un projet SPIP ne prennent jamais racine uniquement dans le code. Elles émergent bien plus souvent des zones floues. Celles où les responsabilités se croisent. Où le savoir se concentre. Où les décisions se prennent à demi-mot.

Quand l'architecture devient opaque et que la stabilité se transforme en contrainte, le facteur humain entre pleinement en jeu. Qui décide. Qui maintient. Qui arbitre. Et surtout, qui porte la vision dans la durée.

Cette seconde partie s'attache à ce qui fait réellement basculer les projets. Non pas l'outil, mais la manière dont il est piloté. La façon dont les rôles sont définis, ou laissés dans le flou. Le moment où SPIP devient le réceptacle de tensions qui ne lui appartiennent pas.

C'est souvent là que l'on parle d'échec. Et c'est précisément là qu'il devient possible de comprendre pourquoi.

Le facteur humain, le plus sous-estimé

Les difficultés d'un projet SPIP sont rarement purement techniques. Elles prennent presque toujours racine ailleurs. Dans l'organisation, dans les rôles, dans la manière dont la responsabilité est distribuée ou, plus souvent, diluée.

Très tôt, un projet SPIP s'appuie sur une ou deux personnes identifiées comme “celles qui savent”. Ce sont elles qui comprennent la logique du site, qui connaissent les subtilités, qui savent où regarder quand quelque chose dysfonctionne. Cette situation est confortable. Elle rassure tout le monde.

La compétence se concentre, pendant que le projet continue d'avancer.

Ce fonctionnement n'est pas problématique en soi. Il le devient quand il s'installe dans la durée sans être questionné. La connaissance reste implicite. Elle circule peu. Elle se transmet encore moins. Le projet repose alors sur une forme d'équilibre fragile, que personne n'a vraiment formalisé.

Un jour, cette personne s'absente. Change de poste. Quitte le projet. Parfois simplement, elle n'a plus le temps. Rien ne casse immédiatement. Le site fonctionne toujours. Mais une inquiétude nouvelle apparaît. Les décisions sont repoussées. Les évolutions deviennent prudentes. On évite de s'engager.

Quand le savoir n'est pas partagé, la peur remplace progressivement la décision.

À cela s'ajoute souvent une gouvernance floue. Personne n'est réellement en charge du long terme. Les arbitrages sont pris au coup par coup, en fonction de l'urgence ou des contraintes du moment. Le technique subit. L'éditorial s'adapte. Et SPIP devient le point de convergence de tensions qui ne lui appartiennent pas.

Dans ce contexte, l'outil finit par porter une responsabilité qui n'est pas la sienne. On lui reproche des lenteurs, des rigidités, des limites. En réalité, ce sont des choix humains non assumés qui s'expriment à travers lui.

SPIP ne décide jamais. Il exécute les décisions, ou les non-décisions, prises ailleurs.

C'est souvent ici que le projet commence à s'enliser. Non par manque de compétence, mais par absence de pilotage clair. Le site devient un espace où chacun agit avec prudence, sans vision partagée. Et cette prudence, à long terme, coûte plus cher que n'importe quelle refonte.

Quand tout se mélange, l'outil devient coupable

À mesure que le projet avance, les frontières s'estompent. Ce qui relève de l'éditorial, du technique ou de l'organisation finit par se confondre. SPIP devient alors bien plus qu'un outil de publication. Il absorbe des attentes qui ne relèvent pas de lui.

On lui demande de compenser un manque de méthode, de corriger des décisions tardives, de pallier une absence de vision. Le site devient le lieu où se cristallisent des frustrations accumulées ailleurs. Délais trop courts. Moyens insuffisants. Arbitrages repoussés. Tout converge.

Quand les rôles ne sont pas clairs, l'outil devient le point de friction.

Dans ce contexte, chaque difficulté prend une dimension disproportionnée. Une évolution éditoriale devient un problème technique. Une contrainte organisationnelle se transforme en limite supposée de SPIP. Le débat se déplace. On discute de l'outil, alors que le sujet est ailleurs.

Progressivement, SPIP endosse un rôle qui n'est pas le sien. Celui de responsable. Responsable des lenteurs. Responsable des compromis. Responsable de ce qui n'a pas été anticipé. Cette lecture est séduisante. Elle simplifie la réalité. Elle évite de questionner les choix collectifs.

L'outil sert alors de paravent à des problèmes qu'on ne veut pas nommer.

À partir de là, le dialogue se tend. Les équipes techniques se retrouvent à justifier l'existant. Les équipes éditoriales expriment des attentes contradictoires. Et le projet avance à contre-courant, porté par une forme d'usure plus que par une dynamique constructive.
SPIP, pourtant, continue de faire ce pour quoi il a été conçu. Il structure. Il affiche. Il publie. Mais il devient aussi le réceptacle de toutes les tensions. Non parce qu'il est défaillant, mais parce qu'il est au centre.

Ce n'est pas l'outil qui échoue. C'est la confusion autour de son rôle.

Pourquoi les projets échouent vraiment

Les échecs des projets SPIP ne sont presque jamais accidentels. Ils suivent des trajectoires récurrentes, que l'on retrouve d'un contexte à l'autre, quels que soient la taille du site ou les moyens engagés.

Le premier facteur est souvent l'absence de vision à long terme. SPIP est choisi pour répondre à un besoin immédiat. Publier vite. Structurer simplement. Mettre en ligne sans dépendre d'un prestataire en permanence. Ces raisons sont légitimes. Mais elles deviennent insuffisantes quand le projet s'installe dans la durée.

Un projet pensé pour démarrer n'est pas toujours pensé pour durer. À cela s'ajoute une perception biaisée de la maintenance. Tant que le site fonctionne, elle est reléguée au second plan. Elle est vue comme un coût, rarement comme un investissement. On préfère ajouter plutôt que consolider. Adapter plutôt que simplifier. Le projet avance, mais il avance sans se renforcer.

Un autre élément revient fréquemment : l'expertise est sollicitée trop tard. On appelle à l'aide quand la situation est déjà tendue. Quand les marges de manœuvre sont réduites. Quand les choix possibles deviennent contraints. Ce n'est pas un manque de compétence, mais un décalage temporel. L'expertise arrive souvent au moment où il n'y a plus vraiment de bonnes options.

Puis vient le moment charnière. Celui où une contrainte nouvelle s'impose. Une évolution attendue depuis longtemps. Une obligation externe. Un besoin devenu incontournable. Ce qui était jusque-là évitable ne l'est plus. Et le projet se retrouve face à lui-même.

C'est là que tout semble se bloquer. Les délais explosent. Les discussions se crispent. Les décisions deviennent difficiles à assumer. On parle alors de refonte, parfois de rupture, comme si une solution radicale pouvait effacer des années de non-décisions.

Les projets ne s'effondrent pas soudainement. Ils révèlent brutalement ce qui était déjà fragile. SPIP n'est ni le déclencheur, ni le responsable. Il est le moment de vérité. Celui où l'on ne peut plus différer, où les compromis accumulés demandent à être assumés. Et c'est souvent à cet instant précis que l'on comprend que l'échec n'est pas technique, mais structurel.

Ce qui change tout, mais qui demande du courage

Éviter ces échecs ne relève pas d'une solution miracle. Il n'y a ni plugin salvateur, ni méthode universelle. Ce qui change réellement les trajectoires tient davantage à une posture qu'à une technique. Accepter de regarder l'existant en face est souvent le premier pas le plus difficile.

Cela suppose de documenter ce qui existe, même imparfaitement. De nommer les choix passés sans chercher de coupable. D'admettre que certaines décisions, pourtant rationnelles à un moment donné, ne le sont plus aujourd'hui. Cela implique aussi de limiter l'empilement, de préférer parfois la simplification à l'ajout, et d'assumer que maintenir un projet vivant demande du temps, de l'attention et une vision partagée.

La maintenabilité n'est pas un luxe. C'est une condition de survie.

Ce courage n'est pas uniquement technique. Il est organisationnel, collectif, parfois politique. Mais lorsqu'il est là, SPIP redevient ce qu'il n'aurait jamais dû cesser d'être : un outil fiable au service d'un projet maîtrisé.

Conclusion.

SPIP comme révélateur de maturité. SPIP n'a rien d'un outil capricieux. Il fait ce qu'on lui demande, longtemps, parfois trop longtemps. Il accompagne des projets dans leurs réussites comme dans leurs angles morts, sans jamais protester.

Ce que l'on appelle un échec SPIP est souvent autre chose. C'est un projet arrivé à un point de vérité. Un moment où les choix passés, les non-choix, les compromis accumulés ne peuvent plus être différés. L'outil n'est alors que le révélateur de ce qui était déjà là.

SPIP ne masque rien. Il amplifie.

En ce sens, il est exigeant. Non techniquement, mais humainement. Il oblige à se poser les bonnes questions. Sur la gouvernance. Sur la transmission du savoir. Sur la manière dont on conçoit un projet dans le temps, au-delà de sa mise en ligne.

En 2026, continuer à faire porter à SPIP la responsabilité d'échecs qui ne lui appartiennent pas n'a plus vraiment de sens. Les signaux sont connus. Les mécanismes aussi. Ce qui manque encore, parfois, ce n'est pas la compétence, mais l'envie de regarder ces signaux en face.

Un projet SPIP qui dure n'est pas un projet figé. C'est un projet qui accepte d'évoluer. Et peut-être est-ce là, finalement, la plus grande qualité de SPIP. Il ne promet pas l'illusion de la simplicité éternelle. Il offre la possibilité d'un projet sincère, à la hauteur des choix humains qui le portent.

Photo de Maarten Deckers sur Unsplash

SPIP en 2026 (1/2) : ce que les non-experts ne voient pas

Teddy Payet — 2026-01-02T08:00:00Z

SPIP est souvent accusé quand les projets déraillent. Trop vieux, trop rigide, pas assez moderne. Pourtant, l'outil tient souvent plus longtemps que les choix qui l'entourent. À travers ce retour d'expérience, je propose un autre regard : celui d'un CMS qui ne casse pas, mais qui révèle, avec le temps, la maturité réelle d'un projet, de son organisation et de ses décisions.

Introduction : SPIP ne casse pas. Les projets, si.

SPIP est rarement le problème.

Quand un projet SPIP échoue, on pointe souvent l'outil. Trop vieux, trop atypique, pas assez moderne. C'est rassurant. Cela évite de regarder ailleurs.

Pourtant, à chaque fois que je suis intervenu sur un site SPIP en difficulté, le constat a été le même : l'outil tenait encore debout. Ce qui flanchait, c'était ce qui l'entourait. Les choix accumulés, les non-décisions, les compromis jamais assumés.

SPIP a cette particularité étrange : il fonctionne longtemps, même quand le projet va mal. Il absorbe les contournements, tolère les bricolages, encaisse les ajouts successifs. Pendant des années, parfois. Jusqu'au jour où l'on demande plus. Une évolution, une mise à jour, une refonte, une contrainte nouvelle. Et là, soudain, tout semble bloqué. Comme si le problème venait d'apparaître.

En réalité, il était déjà là. Silencieux. Progressif. Prévisible.

Cet article n'est pas un procès de SPIP. C'est une tentative de mise en lumière. De ces zones que les non-experts ne voient pas, ou trop tard. De ces angles morts qui ne font pas de bruit tant que tout va “à peu près bien”, mais qui finissent par faire échouer des projets pourtant solides en apparence.
Si SPIP a un défaut, c'est peut-être celui-ci : il ne ment pas. Il révèle, avec le temps, la maturité (ou l'immaturité) d'un projet. Et en 2026, ces révélations ne devraient plus surprendre personne.

Le malentendu fondateur : SPIP n'est pas « simple »

SPIP est souvent présenté comme un outil simple. Simple à installer, simple à utiliser, simple à maintenir. Cette idée s'est installée progressivement, presque naturellement, portée par la facilité de prise en main et par la promesse initiale de publication rapide.

Ce raccourci est compréhensible. Il repose sur une réalité. SPIP permet effectivement de publier sans connaissance technique approfondie. Il rend possible ce que beaucoup d'outils compliquent inutilement. Mais cette accessibilité a été confondue avec une absence de complexité, et c'est là que le premier malentendu apparaît.

Un projet SPIP ne devient pas complexe au départ. Il le devient avec le temps. À mesure que les contenus s'accumulent, que les besoins évoluent, que les usages se précisent. La structure éditoriale se densifie. Les squelettes se spécialisent. Les règles implicites se multiplient. Rien de brutal, rien de spectaculaire. Juste une transformation progressive, presque invisible.

Ce que les non-experts perçoivent encore comme un site simple est déjà devenu un système. Un système cohérent, parfois élégant, mais rarement documenté. Un système qui repose sur des choix faits à des moments précis, souvent dans l'urgence, parfois sans vision à long terme. Et tant que tout fonctionne, ces choix ne sont jamais interrogés.

SPIP ne donne pas l'illusion de la complexité. Il donne l'illusion de la continuité. Le site continue de répondre, les pages s'affichent, les contenus se publient. Cette continuité rassure. Elle masque le fait que le projet a changé de nature.

C'est ici que naît la plupart des incompréhensions. Quand une évolution devient difficile, quand une mise à jour inquiète, quand une refonte semble risquée, on s'étonne. On parle alors d'un outil devenu contraignant. En réalité, ce n'est pas SPIP qui s'est complexifié. C'est le projet qui a grandi sans que son cadre n'évolue avec lui.

L'architecture invisible, là où tout se décide

Un site SPIP ne se construit presque jamais d'un seul tenant. Il s'étire dans le temps. Il se modifie par touches successives, souvent discrètes, parfois urgentes. Une fonctionnalité ajoutée pour répondre à un besoin précis. Un plugin installé pour gagner du temps. Une surcharge créée parce qu'il fallait faire vite. Rien d'illogique. Rien de condamnable.

Le problème n'est jamais un choix isolé. Il est dans la somme des choix. Dans leur accumulation silencieuse, sans remise à plat, sans vision globale. Chaque ajout répond à une contrainte réelle, mais peu d'entre eux sont pensés pour durer. Ils s'empilent, portés par l'idée implicite que l'on pourra toujours faire marche arrière. En pratique, cette marche arrière n'arrive presque jamais.

Avec le temps, une architecture se forme. Elle n'a pas été dessinée, mais elle existe. Elle relie des squelettes à des plugins, des habitudes éditoriales à des comportements techniques, des exceptions à d'autres exceptions. Cette architecture est rarement visible pour ceux qui utilisent le site au quotidien. Elle ne s'affiche nulle part. Elle n'est décrite dans aucun document. Pourtant, elle conditionne tout.

Arrive alors un moment particulier dans la vie d'un projet. Celui où plus personne n'est capable de dire précisément pourquoi telle partie fonctionne comme elle fonctionne. On sait que cela marche. On sait aussi que toucher à cet équilibre pourrait avoir des conséquences imprévisibles. La peur s'installe doucement. Pas une peur consciente, formulée, mais une retenue. On évite certains fichiers. On contourne plutôt que de comprendre. On ajoute au lieu de simplifier.

C'est à ce stade que j'entends souvent la même phrase : "Personne n'ose y toucher." Elle ne traduit pas un manque de compétence. Elle révèle une architecture devenue opaque. Une architecture qui repose sur des enchaînements implicites, sur des décisions anciennes dont le contexte s'est perdu. Le site fonctionne encore, mais il n'est plus vraiment maîtrisé. SPIP, dans ce contexte, joue un rôle particulier. Il n'impose pas de cadre rigide. Il laisse de la liberté. Cette liberté est précieuse au départ. Elle devient dangereuse quand elle n'est pas accompagnée d'une discipline collective. Sans cette discipline, l'architecture devient un produit secondaire du projet, au lieu d'en être un pilier assumé.

Ce n'est généralement pas à ce moment-là que le projet échoue. Il continue. Il avance même, parfois. Mais il avance en se refermant sur lui-même. Chaque évolution coûte un peu plus cher. Chaque décision prend un peu plus de temps. Et surtout, chaque contrainte nouvelle est vécue comme une agression extérieure, alors qu'elle ne fait que révéler ce qui était déjà fragile.
L'architecture invisible n'est pas un défaut technique. C'est un angle mort organisationnel. Tant qu'elle n'est pas nommée, tant qu'elle n'est pas rendue lisible, elle gouverne le projet en silence. Et c'est presque toujours là que tout se décide, bien avant que les difficultés ne deviennent visibles.

Le faux confort de la stabilité

Un site SPIP qui fonctionne depuis longtemps inspire confiance. Les pages s'affichent. Les contenus se publient. Les utilisateurs ne se plaignent pas. Cette stabilité apparente devient un argument en soi.

On s'y accroche facilement. Tant que le site répond, pourquoi le toucher. Tant qu'il remplit sa mission, pourquoi investir. La stabilité rassure parce qu'elle donne l'impression que le temps n'a pas de prise sur le projet.
Pourtant, cette stabilité est souvent un état figé. Les versions ne bougent plus. L'environnement est contraint. Les mises à jour sont repoussées. Non par négligence, mais par prudence. Chaque intervention est perçue comme un risque supérieur au bénéfice attendu.

Progressivement, la stabilité cesse d'être un choix. Elle devient une contrainte. Le projet ne s'adapte plus. Il se protège. Il se replie sur ce qu'il connaît déjà. Le site continue de vivre en surface, mais il cesse d'évoluer en profondeur.

C'est à ce moment précis que le vocabulaire change. On ne parle plus d'amélioration, mais de crainte. Plus de projection, mais de maintien. Les décisions se prennent en fonction de ce que l'on peut éviter, non de ce que l'on pourrait construire.

Le jour où une évolution devient incontournable, la stabilité se fissure. Une obligation nouvelle, une attente différente, un besoin qui ne peut plus être contourné. Ce qui semblait solide révèle alors sa fragilité. Non parce que le site était mal fait, mais parce qu'il n'avait pas été pensé pour évoluer indéfiniment sans être accompagné.

La stabilité n'est pas un état naturel. C'est un équilibre. Et comme tout équilibre, il demande des ajustements réguliers. Sans eux, il finit toujours par rompre.

Conclusion

SPIP ne complique pas les projets. Il les accompagne tels qu'ils sont. Avec leurs forces, mais aussi avec leurs angles morts.

Ce que révèlent l'architecture invisible et le faux confort de la stabilité, ce n'est pas une faiblesse de l'outil, mais une transformation du projet lui-même. À force d'évoluer sans être repensé, il change de nature. Et ce changement, tant qu'il n'est pas nommé, finit par gouverner en silence.
SPIP agit alors comme un révélateur structurel.

Il met en lumière ce qui a été construit, volontairement ou non. Il expose les limites d'un cadre qui n'a pas évolué au même rythme que les usages.

Mais cette lecture reste incomplète. Car derrière l'architecture, derrière la stabilité apparente, il y a toujours des choix humains. Des décisions prises, ou repoussées. Des rôles assumés, ou dilués. C'est là que tout se joue réellement.

À suivre dans la partie 2
Si SPIP révèle les fragilités structurelles d'un projet, il met surtout en lumière celles de son organisation. La suite de cet article s'intéresse au facteur humain, à la gouvernance, et au moment précis où les projets cessent d'avancer pour commencer à s'enliser.

Photo de Anders Jildén sur Unsplash

20 ans de blogging technique : ce que j'ai appris

Teddy Payet — 2025-08-16T12:29:48Z

Depuis 2009, ce blog m'accompagne comme un carnet de route technique. De SPIP aux lignes de commande, des astuces de développement aux projets domotiques, j'y ai consigné mes découvertes, mes erreurs et mes progrès. Quinze ans plus tard, je prends un peu de recul pour partager ce que cette aventure d'écriture m'a appris : documenter pour soi, transmettre aux autres et laisser une trace vivante d'un parcours de développeur qui évolue.

Un chemin commencé en 2009

Mon tout premier article de la rubrique Blog, publié en décembre 2009, portait sur un filtre graphique dans SPIP : un petit bout de code, rien de plus. À ce moment-là, je n'avais pas de plan éditorial ni d'ambition particulière. J'écrivais pour ne pas oublier, pour garder une trace de mes expérimentations. Avec le temps, ces notes éparses sont devenues un journal technique à part entière, un espace vivant où se mêlent astuces rapides, réflexions plus construites et découvertes au fil de mes projets.
En revenant sur quinze années de publications, je réalise que ce blog a suivi le même rythme que ma propre évolution. Il a connu des périodes d'intense activité, des creux inévitables, mais toujours cette constance : revenir écrire quand une idée, un problème ou une solution méritaient d'être partagés.

Les grandes périodes de mon blog

2009–2013 : Les fondations techniques
Lorsque j'ai ouvert la rubrique Blog, je ne pensais pas vraiment à construire une ligne éditoriale. J'écrivais surtout pour moi, afin de conserver quelque part les petits bouts de code et les astuces que je découvrais. SPIP occupait une place centrale dans mes expérimentations. J'y testais les filtres, les boucles, les façons d'améliorer l'affichage ou d'optimiser mes squelettes. Beaucoup de mes articles de cette période sont courts, précis, et volontairement très pratiques. Ils reflètent un quotidien de développeur-intégrateur en construction, avide de solutions concrètes.

Ce foisonnement technique a constitué une véritable fondation. Non seulement il m'a permis d'apprendre plus vite en formalisant mes découvertes, mais il m'a aussi donné un sentiment d'appartenance à une communauté plus large. Chaque billet publié devenait une petite pierre ajoutée à l'édifice collectif du web libre.

2014–2018 : Moins de volume, plus de spécialisation
Après cette période d'intense production, le rythme s'est ralenti. Les années 2014 à 2018 ne comptent qu'une poignée d'articles, mais ceux-ci sont plus ciblés. Je n'avais plus besoin de consigner chaque manipulation, chaque filtre ou chaque commande. Mon blog a pris une autre fonction : celle de mémoire technique. J'y revenais surtout quand une solution méritait vraiment d'être fixée, ou lorsqu'un sujet demandait un peu plus de recul.

On y voit apparaître de nouveaux thèmes, notamment l'industrialisation du développement avec l'arrivée de Git, mais aussi des réflexions plus transverses sur l'organisation de mes projets. Cette période marque un passage de l'accumulation de notes à une sélection plus rigoureuse de ce que je jugeais utile de partager. Il m'arrivait parfois de rassembler un ensemble de références, d'articles, de tuto dans un seul et même article sur mon blog. En effet, quand on rencontre une difficulté dans un développement, on regarde les solutions sur Stack Overflow, ou toute autre source. La solution n'était pas systématiquement dans la même source mais au sein de plusieurs. Au lieu de m'arracher les cheveux plus tard à refaire ce parcours, je mettais tout ça dans un article.

L'article "Petits réglages pour symfony sous Mac OSX" est un exemple concret de cela. Lors de ma formation en tant que développeur multimédia, j'apprenais le développement avec Symfony (pfiuuuu la v2 !) et on devait faire un réglage particulier. 5 ans après sa mise en ligne, je recevais encore des remerciements de personnes qui avaient rencontré le même problème !

2019–2021 : Relances ponctuelles
Le blog connaît ensuite une phase plus irrégulière. Quelques articles apparaissent, souvent liés à mes outils du quotidien. J'écris sur VSCode, sur Git, sur des pratiques de développement qui se sont imposées au fil des années. Le blog devient alors une sorte de miroir de mon environnement de travail. Je ne publie pas souvent, mais chaque article porte une trace claire de ce que j'utilise réellement. Je ne cherche pas à faire comme les autres : des articles à la mode. Certes, le blog ici présent est professionnel, ce n'est pas un journal personnel mais on y ressent toutefois mon évolution.

C'est une période où je ne cherche pas à maintenir un rythme de publication. Je laisse venir les sujets. Je préfère la qualité à la quantité, quitte à publier rarement. Ces articles isolés marquent pourtant des jalons importants de mon évolution professionnelle, puisqu'ils correspondent à une transition dans mes outils et mes méthodes. Cette période a été pour tout le monde incertaine... à cause du COVID. Étant confiné, nous avions du temps, j'avais du temps. Je me suis mis à la domotique et j'ai jeté sur le papier (numérique) mes pas à pas pour la mise en place de ma domotique avec MagicMirror2. Mais cela a été, comme pour beaucoup, une période de remise en question...

2022–2025 : Renaissance et diversification
À partir de 2022, et plus encore en 2024, une nouvelle dynamique s'installe. Le blog reprend vie avec des sujets qui dépassent le seul cadre du développement web. La domotique devient un fil rouge, avec Home Assistant et MagicMirror comme terrains d'exploration privilégiés. J'y raconte mes scénarios, mes tableaux de bord, mes expériences d'automatisation. Ces articles sont souvent plus narratifs, plus proches de mon quotidien, tout en restant très techniques.

Cette renaissance ne signifie pas un abandon de SPIP. Au contraire, SPIP reste présent comme une base solide, mais il cohabite désormais avec d'autres univers. Le blog devient le lieu où je croise mes compétences de développeur web avec mes envies d'expérimenter dans la maison connectée. On y sent une maturité nouvelle : je n'écris plus seulement pour garder une trace, mais aussi pour transmettre une vision, pour relier mes savoir-faire à des usages concrets qui parlent à d'autres.

Ce que j'ai appris en 15 ans de blogging technique

Au début, j'écrivais sans autre intention que de me créer une mémoire technique. Une astuce notée, un filtre documenté, et je savais que je pourrais y revenir sans perdre du temps.

Puis j'ai découvert que ces articles servaient aussi à d'autres.

Avec le temps, j'ai vu mes thématiques évoluer. D'abord centrées sur SPIP, elles se sont élargies vers le PHP, les outils de développement, puis la domotique et Home Assistant. Ce mouvement naturel a fait du blog un miroir de mes pratiques réelles. Il illustre le fait qu'un blog n'est pas figé : il vit, se transforme, et accompagne son auteur dans ses propres changements. Cette liberté d'évolution est ce qui l'a maintenu pertinent pour moi comme pour mes lecteurs.

L'écriture elle-même a été une école. Pour publier un article, même court, il faut organiser ses idées, clarifier un raisonnement, trouver des mots justes. Ce travail m'a appris à mieux expliquer, à vulgariser, à rendre mes pratiques compréhensibles. Cette compétence, acquise peu à peu, dépasse largement le cadre du blog et rejaillit sur ma manière de collaborer.

Il m'a aussi fallu apprivoiser l'irrégularité. Certaines années foisonnent d'articles, d'autres sont plus creuses. J'ai longtemps perçu ces silences comme des manques, avant de comprendre qu'ils faisaient partie du rythme. Un blog ne se mesure pas à la fréquence hebdomadaire ou mensuelle, mais à la continuité sur le long terme. Chaque retour d'écriture enrichit le fil, même après une pause.

Enfin, il y a l'impact professionnel. Le blog m'a donné une visibilité dans la communauté SPIP, renforcé mon image de développeur partageur, et laissé des traces concrètes de mon évolution. Mais le bénéfice le plus profond reste personnel : voir s'accumuler ces fragments de mémoire, année après année, et sentir que j'ai bâti une archive vivante de mon propre chemin.

Les défis rencontrés

Le premier défi a été la régularité. Publier sur un blog demande une constance qui se heurte très vite aux contraintes de la vie professionnelle et personnelle. J'ai connu des années de forte activité, où j'enchaînais les articles presque naturellement, porté par mes découvertes et mon enthousiasme. Mais j'ai aussi traversé des périodes beaucoup plus silencieuses, où l'envie d'écrire ne trouvait pas sa place dans un quotidien chargé. Le défi n'était pas seulement de trouver le temps, mais surtout de garder la flamme. À chaque pause, je me suis demandé si je reviendrais. Et chaque fois, j'ai fini par rouvrir l'éditeur et recommencer, preuve que l'écriture était devenue pour moi une habitude de fond, une discipline ancrée au-delà des aléas.

Un autre défi important a été l'adaptation aux évolutions techniques. Entre 2009 et 2025, les outils ont radicalement changé. J'ai commencé à écrire dans un contexte dominé par SPIP, le PHP artisanal et des feuilles de style construites à la main. Puis il a fallu intégrer Git, comprendre les frameworks, apprivoiser les environnements modernes, et plus récemment m'ouvrir à la domotique. Chaque saut technologique m'a obligé à réinventer mes sujets, à revoir ma façon de présenter les choses. Ce n'était pas seulement une mise à jour technique, mais aussi un effort d'écriture : comment expliquer autrement, avec des mots simples, des réalités devenues plus complexes.

Le blog a aussi rencontré ses limites en termes de visibilité. À une époque où les réseaux sociaux ont pris une place énorme, il peut sembler plus simple de poster une solution sur Twitter, Mastodon ou un forum que de rédiger un article complet. Tenir un blog suppose de résister à cette tendance, de garder l'ambition d'un espace autonome, qui ne se dilue pas dans le flux éphémère.

Un autre défi a été l'équilibre entre notes personnelles et contenu utile aux autres. Écrire pour soi est simple, mais écrire pour être lu impose un effort supplémentaire.

Il y a aussi le défi de la motivation, parfois émoussée après des années de publication.

Enfin, il y a le doute, toujours présent : est-ce que ce que j'écris est pertinent ?

Ce que je referais différemment

Avec le recul, il y a des choix que j'aurais pu affiner dès le départ. Par exemple, poser une ligne éditoriale plus claire entre mes notes brutes et mes articles construits.

J'aurais aussi aimé organiser plus rigoureusement les mots-clés et les catégories. Cela m'aurait permis d'exploiter pleinement l'indexation et de faciliter la navigation pour mes lecteurs. De petites décisions prises tôt peuvent avoir un grand impact sur la structure d'un blog.

Un autre point concerne la diversité des sujets. La domotique, par exemple, m'a séduit bien avant 2020 grâce aux contenus DIY et aux chaînes Youtube que je suivais. Pourtant, je n'ai trouvé un cadre concret pour l'appliquer qu'à partir de cette date, dans mon quotidien à la maison. J'aurais pu en parler plus tôt, ne serait-ce que sous forme de veille ou de découvertes, même si ce domaine reste pour moi personnel et en dehors de toute sphère professionnelle.

Il y a également la question du ton. J'aurais pu oser davantage un style personnel, en assumant la part de récit qui rend certains billets plus vivants. La technique pure est utile, mais les anecdotes et le contexte donnent souvent une valeur supplémentaire.

Enfin, si c'était à refaire, je travaillerais davantage sur la mise en valeur visuelle de mes articles. Non pas pour rechercher l'effet esthétique, mais pour accompagner la lecture, donner des points d'appui, et rendre mes contenus plus accessibles dans la durée.

Conclusion : pourquoi continuer en 2025

Écrire reste nécessaire.

Un billet, même simple, peut encore trouver son utilité. Un blog vieillit bien mieux que les réseaux sociaux. Et il conserve une force que l'instantané ne peut pas offrir.

Continuer en 2025, c'est d'abord prolonger une habitude. Mais c'est aussi réaffirmer un choix : celui d'un espace indépendant, où je décide du rythme, des sujets, du ton. Je ne cherche pas la course à l'audience, mais la cohérence d'un journal technique qui suit son auteur sur la durée. Un blog n'a pas besoin d'être bruyant pour être utile.

Chaque article publié est une brique ajoutée à un édifice qui se construit lentement. Certains articles restent des notes rapides, d'autres deviennent des repères durables. Et parfois, un billet écrit presque pour moi se révèle précieux pour d'autres, plusieurs années après. C'est ce décalage temporel qui fait la richesse du blogging. La valeur d'un article ne se mesure pas au nombre de vues le lendemain de sa parution, mais à sa capacité à rester utile dans le temps.

En 2025, j'ai envie de continuer pour plusieurs raisons. Parce que j'apprends toujours en écrivant. Parce que j'éprouve du plaisir à relire mes propres archives et à y voir mon chemin. Parce que je sais que ce blog n'est pas seulement mon aide-mémoire, mais aussi un pont tendu vers ceux qui passent par les mêmes questions techniques. Parce qu'il m'offre un espace de liberté, loin des formats contraints des plateformes. Parce que la régularité imparfaite de mes publications n'a jamais été un frein, mais plutôt la preuve qu'il accompagne ma vie, telle qu'elle est. Parce que la transmission fait partie de ma façon de travailler et de partager. Parce qu'un billet bien construit vit longtemps et continue de voyager tout seul. Parce que dans ce blog, je retrouve à la fois un miroir, une trace et un terrain d'expérimentation. Et parce que, tout simplement, je ne pourrais pas vraiment arrêter d'écrire, tant c'est devenu une habitude ancrée.

Je suis aussi une personne cérébrale. J'aurais mille sujets personnels à explorer, sur ma vision de la vie ou sur le développement personnel, sans prétendre donner de leçons, simplement pour exprimer ce que je suis. Mais j'ai choisi de garder ce site et sa rubrique blog dans une dimension technique et professionnelle. Peut-être qu'un jour, j'ouvrirai un autre espace, dédié au développement personnel. Ici n'est pas le lieu que j'ai retenu pour cela.

Écrire, encore et encore, même sans obligation, même sans calendrier fixe, reste une manière de relier mon présent à mon passé et d'ouvrir la porte à l'avenir.

Au plaisir de découvrir vos retours, vos histoires et d'échanger autour de ces parcours partagés.

Photo de Nick Morrison sur Unsplash

Automatisation et scripts bash, gagner du temps au quotidien

Teddy Payet — 2024-07-15T07:00:00Z

Salut à tous ! Aujourd'hui, nous allons plonger dans l'univers fascinant de l'automatisation avec les scripts Bash. Que vous soyez un développeur web ou un administrateur système, les scripts Bash peuvent vous faire gagner un temps précieux en automatisant des tâches répétitives. Prêts à découvrir comment devenir plus efficaces au quotidien ? C'est parti !

Pourquoi automatiser avec Bash ?

Comme vous avez pu le voir en parcourant mes différents articles, j'utilise beaucoup de script bash pour automatiser des actions. J'ai une règle : "Si on réalise plus de 2 fois une action, nous pouvons l'automatiser". L'automatisation permet de se concentrer sur les tâches à forte valeur ajoutée en laissant les scripts faire le travail répétitif. Bash, l'un des langages de script les plus couramment utilisés sur les systèmes Unix et Linux, est parfait pour cela. Voici quelques avantages de l'automatisation avec Bash :

Gain de temps : Les scripts exécutent rapidement des tâches qui prendraient beaucoup de temps manuellement.
Réduction des erreurs : Automatiser minimise les risques d'erreurs humaines.
Productivité accrue : Vous pouvez automatiser les sauvegardes, les déploiements et bien plus encore.

Les bases de Bash : comment débuter ?

Pour commencer avec Bash, il suffit d'ouvrir votre terminal et de créer un fichier script. Voici un exemple simple de script Bash pour vous familiariser :

#!/bin/bash echo "Bonjour, monde !"

Enregistrez ce script dans un fichier nommé "bonjour.sh", puis donnez-lui les permissions d'exécution avec la commande suivante :

chmod +x bonjour.sh

Enfin, exécutez le script avec :

./bonjour.sh

Voilà, vous venez de créer et d'exécuter votre premier script Bash !

Automatiser les tâches courantes

Voyons maintenant quelques exemples concrets d'automatisation avec Bash.

Sauvegardes automatiques : Créez un script pour sauvegarder régulièrement vos fichiers importants.
```
#!/bin/bash tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier
```
Ce script crée une archive compressée de votre dossier et y ajoute la date du jour.
Nettoyage de fichiers temporaires : Un script pour supprimer les fichiers temporaires peut libérer de l'espace disque.
```
#!/bin/bash rm -rf /tmp/* echo "Fichiers temporaires supprimés."
```

Déploiement de site web : Automatisez le déploiement de votre site avec un script.

#!/bin/bash cd /chemin/vers/votre/site git pull origin main echo "Site mis à jour avec succès."

Vous pouvez voir aussi sur mes différents articles d'autres utilisations que j'ai avec les scripts Bash :

Meilleures pratiques pour écrire des scripts Bash

Pour que vos scripts soient efficaces et maintenables, voici quelques bonnes pratiques à suivre :

Utilisez des commentaires : Expliquez ce que fait chaque section de votre script.

#!/bin/bash # Ce script sauvegarde un dossier tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier

Vérifiez les erreurs : Utilisez des structures conditionnelles pour gérer les erreurs.

#!/bin/bash if [ -d /chemin/vers/dossier ]; then tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier else echo "Le dossier n'existe pas." fi

Créez des scripts modulaires : Évitez les scripts trop longs en les divisant en fonctions.

#!/bin/bash sauvegarder() { tar -czf sauvegarde_$(date +%F).tar.gz /chemin/vers/dossier echo "Sauvegarde terminée." } sauvegarder

Outils pour améliorer vos scripts

Plusieurs outils peuvent vous aider à écrire de meilleurs scripts Bash :

ShellCheck : Un linter pour détecter les erreurs dans vos scripts Bash. ShellCheck
Bash-it : Un framework pour améliorer votre configuration Bash avec des plugins et des thèmes. Bash-it

Pour résumer

L'automatisation avec les scripts Bash est un moyen puissant de gagner du temps et d'augmenter votre productivité. En suivant les bonnes pratiques et en utilisant les outils adéquats, vous pouvez simplifier de nombreuses tâches quotidiennes. J'espère que cet article vous a donné des idées pour commencer à automatiser vos propres tâches.

N'hésitez pas à partager vos expériences et vos scripts Bash préférés dans les commentaires. Quels sont les scripts que vous utilisez le plus souvent ? Quels défis avez-vous rencontrés ? Partageons nos astuces et apprenons ensemble !

N'attendez plus, lancez-vous dans l'automatisation et faites de Bash votre allié du quotidien !

L'automatisation avec Bash peut transformer votre façon de travailler. Partagez vos expériences, posez vos questions et construisons ensemble une communauté de développeurs plus efficaces et collaboratifs !

Photo de Gabriel Heinzer sur Unsplash

Je suis passé à SPIP 4.0

Teddy Payet — 2021-09-14T06:00:00Z

Ça y est ! Je suis passé à SPIP 4.0 ! Je ne sais pas si vous avez suivi, mais SPIP 4.0 est sorti cet été pour ses 20 ans. Il y a pas mal de petites nouveautés, je vous laisse lire l'article sur le Blog de SPIP qui en parle très très bien.

Introduction

Je me suis décidé à passer à SPIP 4.0 en cette rentrée 2021. Pour être honnête, j'avais un peu peur de ce passage car j'avais quitté un peu l'actualité de SPIP (ses développements, son évolution, etc.). Je ne savais pas où j'allais mettre les pieds même si j'ai toujours aimé ce CMS. Je vais vous parler de mon chemin vers son adoption.

Par beau temps

Mon site était sous SPIP 3.2.9. Et j'utilise Zcore avec un template maison basé sur Bootstrap. Jusque là, rien de bien méchant. J'ai décidé de profiter de cette montée de version de SPIP pour revoir mon template et avoir également la dernière version de bootstrap : 5.1.1

J'ai dû retravailler les différentes classes que j'avais. Pas trop méchant. J'ai fait les choses étape par étape. Avant de migrer pour SPIP 4.0, j'ai fait la mise à jour de SPIP en 3.2.11 qui permet d'avoir la compatibilité PHP 7.4 (la version minimum pour SPIP 4.0 est PHP 7.3).

Mon hébergeur, OVH pour ne pas le citer, prend en charge cette version de PHP. Ouf.

Début septembre, j'ai mis en ligne mon template avec bootstrap 5.1.1 et SPIP 3.2.11. Cela me laissait le temps de tester en "live" la compatibilité avec PHP 7.4. Une lettre à la poste par beau temps !

Puis vint la pluie…

SPIP 3.2.11, PHP 7.4, Boostrap 5.1.1, c'était trop beau pour être vrai ! J'ai testé en local le passage à SPIP 4.0. Depuis le back-office, belle page avec la nouvelle interface de l'espace privé. Responsive, prenant toute la largeur de la fenêtre, c'est beau ! Certains diront que l'espace privé n'a pas changé depuis sa création, mais en fait tout a changé ! Il est plus light, plus agréable avec ces nouveaux jeux d'icônes SVG.

Puis, j'ai cliqué sur le bouton "voir le site public"… Et patatra ! La page met du temps à se charger… Je me dis que ce n'est que le cache qui se recalcule… Et ben non, j'ai une belle erreur php me disant soit que je n'ai suffisamment de mémoire allouée (mouais… 128Mo puis 256Mo…), soit qu'il ne trouvait pas une variable dans les scripts php…

Panique à bord !

Je cherche… désespérément… Je regarde mes scripts PHP maison en pensant trouver la bonne piste… Et non, rien y fait. J'y passe des heures sur le sujet, je change même d'environnement : d'un raspberry Pi avec LAMP, je passe sous MAMP sur mon mac et même en preprod sur mon espace d'hébergement. Rien y fait. Toujours ces erreurs aléatoires. Pourtant, tout fonctionne sous SPIP 3.2.11 en PHP 7.4.

Je sais que la gestion des documents et des logos a changé sous SPIP 4.0. Et j'utilise avec grand plaisir les filtres sur mes templates. Je décide alors d'aller vers cette piste.

Mes images sur mon site sont en moyenne à 2500px de largeur. Ça me permet d'avoir des images de bonnes dimensions et de pouvoir les redimensionner selon mon design. Je décide de venir à une version plus allégée de mes filtres. Suppression des filtres image_passe_partout, image_recadre, image_aplatir et j'en passe. Rien y fait !

Je peste sur mon idée de passer à SPIP 4.0 avec la méthode R.A.C.H.E. Même en sachant que SPIP 4.0 avait changé son approche pour les logos, je ne pensais pas que cela allait être aussi compliqué.

J'utilise un modèle nommé "logo.html". Ce modèle me permet de ne pas dupliquer mes filtres pour les visuels de mes articles, rubriques et cie. Je décide de l'ouvrir dans PHPStorm par raccourcis clavier "Search everywhere". Je tape donc modeles/logo.html. Et OH ! Surprise ! le plugin medias utilise un modèle logo en SPIP 4.0.

Ah tiens… En fait, j'étais tellement subjugué par la nouvelle interface que je n'avais pas remarqué qu'aucun de mes logos d'articles ne s'affichait. J'ai regardé en base de données dans la table spip_documents comment SPIP indique les logos d'articles. Je pige le truc rapidement. J'adopte la méthode R.A.C.H.E… La migration des données par SPIP n'a pas bien insérée les "anciens" logos dans la table de documents. Que cela ne tienne ! Je crée un petite fonction PHP qui va insérer dans la bdd mes logos d'article (de rubriques et de sites) en respectant les bons chemins (exemple : logo/arton-XX.png). Ça se fait rapidement.

Je reviens au fichier modeles/logo.html du plugin medias. Je consulte ce fichier et constate son extrême simplicité et efficacité :

[][(#ENV{lien}|?{})]

Je n'ai pas trouvé exactement où était appelé ce fichier. Mais j'ai pour principe de ne jamais utiliser les même noms que dans un framework. Cela évite les effets de bord indésirables. Donc, je renomme mon modèle maison en modeles/visuel.html. Cela colle bien à son utilisation première.

Une île paradisiaque au loin

Suite à ce renommage, je commence à avoir de nouveau un début de page sur mon espace public. Il y a encore quelques petits effets à régler. Des warnings plus compréhensibles. Je m'attèle à régler ça.

J'adopte de façon systématique (pas comme les antibiotiques) l'utilisation de modeles/visuel.html, je vide les répertoires local, tmp/cache et tmp/logs/ avant chaque grosse modification. Le site est à nouveau opérationnel et je retrouve le même template que j'utilisais en SPIP 3.2.21 en production en début de mois de septembre.

Je respire enfin. L'espoir en moi renait.

Un avenir radieux

Je teste toujours sur mon propre site la dernière version de SPIP avant de la proposer à mes clients. Ainsi, j'aurais déjà essuyé les plâtres. Il sera plus simple pour passer la peinture chez les clients.
L'erreur était toute bête, mon modèle logo gênait SPIP dans sa nouvelle monture. Ma surcharge changeait le comportement attendu. Je suis incapable de dire exactement pourquoi cela faisait planter PHP. Je n'ai pas cherché à le savoir non plus pour être franc.

Je constate surtout que SPIP est plus rapide. Merci PHP 7.4, merci à la core team d'avoir rendu SPIP plus léger et véloce. Je sais que si je passe à PHP 8.0, cela sera encore plus rapide. Mais j'ai plusieurs sites sur mon hébergement OVH qui ne sont pas compatibles PHP 8.0.

Vous pouvez consulter le résultat de cette migration en lisant cet article. En effet, en ce mardi 14 septembre, mon site est officiellement sous SPIP 4.0 sous vos yeux ébahis !

Et la suite ?

J'ai commencé à travailler sur mes plugins de la communauté pour une compatibilité avec SPIP 4.0 :

Info SPIP
Socicon
Lister les constantes PHP de SPIP
Lister les pages de configuration
Lister les pages ?exec=xxx
Lister les fonctions PHP de SPIP
Lister les objets principaux de SPIP
Lister les dossiers
Commits de projet
jQuery Vector Maps
Projets (je ne fais que la maintenance de ce plugin, je n'en suis pas le créateur, je tiens à le préciser)
Sites pour projets

Il m'en reste quelques uns à migrer dont le plus gros : InfoSites. Il est dans les bacs. Il est dépendant d'un plugin qui est en attente de mise en compatibilité avec SPIP 4.0. Plus qu'un pour pouvoir livrer la v2 de ce plugin qui me tient à cœur.

Fin de vie pour…

La liste précédente est plutôt longue. Mais il y aura des "laissés pour compte" dans la course à SPIP 4.0. En effet, selon ma vision, un plugin n'a plus lieu d'être :

Agrandir la largeur de page (SPIP_hop pour les intimes) : l'interface de l'espace privé a été revu pour prendre toute la largeur de la fenêtre et va même plus loin que ce qu'offrait spip_hop. Je ne vois pas l'utilité de le maintenir pour SPIP 4.0

Pour le moment, je n'ai plus le temps/besoin pour certains autres plugins. Donc leur mise à jour est repoussée à une date ultérieure :

Déréférencer les médias ;
Nettoyer la médiathèque.

Voilà le périple que j'ai connu avec SPIP 4.0. Je n'ai pas de regrets pour mon passage vers cette dernière version. Au contraire. :-)

La domotique et moi, 2ème partie

Teddy Payet — 2020-04-29T07:00:00Z

Alors, avez-vous pu lire la 1ère partie ? Si cela n'est pas fait, je vous invite à le lire avant d'entamer la lecture du présent article. C'est fait ? Parfait.

Je vais continuer de vous exposer simplement et concrètement ma vision de la domotique, ce qui m'y intéresse. Nous allons voir les points suivants :

L'accessibilité, l'interface homme/machine
Le contrôle et l'automatisation
L'open source

L'accessibilité, l'interface homme/machine

De part mon expérience professionnelle et au fil de mes rencontres, j'ai acquis la conviction que l'utilisateur doit pouvoir prendre la main sur la machine (Skynet ?). De ce fait, si je ne peux contrôler un produit manuellement sans passer par internet ou autre, alors c'est une mauvaise intégration du produit.

Il en va de même pour les solutions logicielles accompagnant ces produits qui doivent être simples de prise en main. En effet, par exemple, ma femme doit pouvoir configurer/désactiver une alarme sans devoir toucher à une seule ligne de codes. De même, mes enfants doivent pouvoir commander une lumière sans difficulté particulière.

Un second volet de l'accessibilité est le code source de ce que j'utilise pour contrôler mes appareils connectés. J'utilise des produits de différentes marques, mais ils doivent pouvoir communiquer entre eux. Si une solution open source existe, j'irai vers cette solution. Mais si une solution payante et abordable fait la même chose en moins compliquée et plus ergonomique, je testerai cette solution. Si elle s'avère fiable, je prendrais cette solution payante.

Encore une fois, quelque soit la solution, je dois pouvoir interagir avec elle depuis ma centrale, ma “box” domotique.

Le contrôle et l'automatisation

Le nerf de la guerre ! Pouvoir contrôler et automatiser est essentiel dans la domotique. Ici, ma philosophie de développeur prend les devants : si je fais une action plus de 2 fois, alors c'est que je peux l'automatiser ou la simplifier. Si je ne sais pas le faire, c'est que je n'ai pas la connaissance pour le moment de le faire.

Grâce à cet état d'esprit, en outre de pouvoir contrôler par la voix les lumières, je réfléchis systématiquement à comment simplifier notre vie au quotidien.

Tous les jours, à 00h25, le mode nuit s'active à la maison (extinction de toutes les lumières, volume des GHM et d'Alexa à 10%). A 6h30, le mode jour se met en place (volume des médias players à 60%). Ceux sont des actions très simples. Une autre automatisation est d'allumer la lumière de la pièce de vie si le soleil s'est couché et qu'il y a du monde à la maison.

Je pourrais automatiser encore des éléments dans l'appartement mais il me faut quelques capteurs de plus pour y arriver. Chaque chose en son temps.

Open source

Comme je l'ai déjà abordé précédemment, je préfère des solutions open source. Malheureusement, ce n'est pas toujours possible, surtout dans un pays francophone. En effet, si je désire avoir un contrôle par la voix des mes produits, il existe pléthore de solutions open source d'assistants personnels virtuels (Mycroft, Kalliope, Stephanie, Open Assistant, Jasper, Jarvis, etc.) Si ces solutions ont le mérite d'exister, les voix sont anglaises. Je ne suis pas contre, mais tout le monde n'est pas bilingue à la maison. Si des solutions avec des voix françaises existent, elles sont payantes, avec licence.

Ceci est un point important notamment pour mon choix de Google Home Mini. Google est très en avance sur le contrôle par la voix dans plusieurs langues. De plus, Google a mis à disposition des API qui permettent des interactions avec ses appareils.

Toutefois les Google Home Mini ne seront chez moi qu'une interface vers ma domotisation. J'ai fait des recherches sur internet de solution de “système domotique” :

OpenHab
Home Assistant
Jeedom (Cocorico ! Une solution française)
Domoticz

Ceux sont les noms que j'entendais le plus parler sur la toile. Mon choix pour ces 4 solutions est basé sur plusieurs critères :

Rapide à prendre en main ;
Compatible Raspberry Pi 3 ;
Flexible ;
Communauté importante et réactive ;
Bien documenté ;
Pas de licences à payer (ben oui, on est en open source là)
Un maximum de compatibilité avec des produits/API ;
L'esthétique de l'interface.

La décision finale s'est portée sur Home assistant. Il est compatible avec beaucoup d'outils que j'utilise déjà. Ce qui a fait pencher la balance est également un des Youtubers que je suis : DrZzs. Son discours dans les vidéos de sa chaîne m'a conquis. De plus, Home Assistant a le vent en poupe en France. Je ne m'éterniserai pas plus sur ce choix car cela n'est pas le but du présent article. Mais une série d'articles apparaîtra prochainement sur le sujet.

Quoiqu'il en soit, j'ai installé Home Assistant sur mon Raspberry Pi 3+ sur une carte MiniSD de 32Go grâce à Hass.io. Après quelques configurations, il n'y a que Home Assistant (Hass.io ou HA pour les intimes) qui sera connecté à des solutions propriétaires telles que Google (cf. Google Assistant). J'ai ajouté à HA une clé USB Conbee 2 qui me permet de contrôler des produits compatible avec le protocole Zigbee. Comme Google Assistant est connecté à mon compte Hass.io, il ne verra que du feu quelque soit le protocole que j'utiliserai sur HA. Magique. Un seul point d'entrée.

Conclusion

Voici ma vision de la domotique ou du moins ce qui m'intéresse dans la domotique. Je n'ai pas abordé tous les points de la domotique tels que la vidéo-surveillance (caméras) ou la sécurité (les serrures connectées), j'en parlerai peut-être plus tard. Tout le monde n'a pas la même vision de la domotique ni les même centres d'intérêts. Mon épouse n'aime pas être envahie par les “robots” (encore toi Skynet ?), elle veut pouvoir décider par elle-même de ce qu'elle désire faire (et elle a raison). Moi, j'aimerai aider mes enfants à être plus autonomes et également pouvoir avoir un oeil protecteur sur eux (ils ont 5, 10 et 13 ans). A cela, j'aimerai me faciliter la vie (flemmard un développeur ? “C'est pas faux”).

Au fil du temps et de mes installations, je voudrais rendre plus discret la domotique et indispensable.

La domotique et moi, 1ère partie

Teddy Payet — 2020-04-27T07:00:00Z

Je voulais aborder ce sujet depuis un moment déjà : ma vision de la domotique. Comme vous avez pu le lire sur mon blog, j'ai quelques articles qui tendent vers ce domaine ou plus exactement un assistant personnel. Le MagicMirror est un helper, une sorte de mini assistant personnel mais n'est pas de la “home automation”. Je vais essayer de partager avec vous ma vision. Je n'essaie pas de vous convaincre, j'essaie juste de poser sur le papier mon concept. Ce qui permettra de vous faire comprendre ma ligne éditoriale sur le sujet dans mes articles.

Mon profil avant tout

Avant de commencer de vous parler de la domotique pure et dure, je voudrais surtout me présenter pour que vous puissiez comprendre mes possibilités, mes compétences mais aussi mes limites.

Je suis de formation initiale graphiste ou “designer”. J'ai découvert le monde du web et notamment du développement de façon autodidacte. Je suis aujourd'hui Lead Developer PHP. J'installe des VM linux pour mes développements (merci vagrant). Donc, je n'ai pas vraiment peur de lire des lignes de code si besoin et d'en écrire (si je connais ou comprends le langage de programmation de la solution domotique). Je suis curieux des nouvelles technologies en général, de la SF (ne me demandez pas mon auteur favori, ça ne servira à rien, je n'en ai pas), de l'actualité en général, de l'interaction homme-machine (mais la plus basique qui soit : le comportement d'un utilisateur lambda devant une technologie). Je regarde énormément de Youtubers Makers, DIYers, etc.

Ça, ceux sont mes points “forts”. Maintenant, mes lacunes :

Quand on parle de domotique, souvent, on parle de DIY… Oui, mais je ne fais pas de soudure, pas d'électronique (mon dernier calcul de résistance date d'il y a 25 ans au collège), pas d'impression 3D (pas la place pour le moment). De ce fait, je préfère des solutions ou des produits finis. Je ne saurais pas brancher un ESP8266 avec un relay… Ni même flasher ce même ESP8266…

Dernier point, ma famille et moi-même vivons dans un appartement. Nous ne pouvons pas faire de grands travaux/bricolages pour mettre en place la domotique.

Inspecteur gadget

Comme dirait ma femme, “c'est gadget !”. Oui, ce n'est pas faux de prime abord. Vous vous en doutez, au fil de la lecture de mon blog, vous avez pu voir que je suis un geek, un technophile. Mais j'ai une fibre de “designer”, d'expérience utilisateur.

J'ai démarré l'installation de ma “domotique” avec le MagicMirror pour avoir un tableau de bord. C'est un projet “gentillet” pour démarrer, pour me frotter à cet univers. Le système me paraissait accessible. Je ne me suis pas trompé. Très très rapidement, la deuxième étape était l'installation d'interrupteurs connectés, de la marque Sonoff. Peu cher et facile à installer chez moi. Il y a un aspect financier qui m'intéresse dans la domotique : acheter du matériel abordable. Mais qui dit abordable, ne dit pas de mauvaises qualités.

Par la suite, j'ai pu acheter 2 Google Home Mini pour le prix d'un.

Mon écosystème a commencé à se mettre en place. Des interrupteurs connectés, des Google Home Mini et un Raspberry Pi (celui du Magic Mirror) pour les commander tous. Je ne saurais vous dire exactement combien j'ai dépensé pour faire tout ça, mais ce n'est pas excessif car étalé sur 1 an environ. Pour preuve, j'ai aujourd'hui cet équipement :

3 interrupteurs Sonoff Touch
2 contrôleurs Wifi monocouleur MagicHome
1 prise Zigbee
2 Raspberry Pi 3
Une clé Conbee2
5 Google Home Mini
1 Alexa Echo Dot

J'ai un Google Home Mini (GHM) par pièce principale, j'en ai payé 3 sur 5 à moitié prix lors de promo à chaque fois. Certains, et je peux comprendre, pourront dire que j'offre mes données à une grosse entreprise… Oui, certes. Mais on y reviendra plus tard sur ce sujet spécifique. Les Google Home Mini me permettent de commander mes lumières par la voix, entre autres.

J'ai d'autres utilisations marrantes des GHM. Ce qui ne déplaît pas à mes enfants.

Entre autres, je cherche des produits/solutions ouvertes, au mieux open source. Les Google Home Mini ne sont pas open source, elles sont d'un écosystème propriétaire mais Google permet d'interagir avec leurs produits grâce à des API/SDK gratuitement. Donc, cela me va très bien.

L'économie financière

Il n'y a pas à dire sur le sujet, un des buts de la domotique est l'économie financière ! Si on met en place une domotique sur le chauffage (commande de la température lorsque les personnes sont présentes ou pas à la maison, ouverture des fenêtres, etc.), on peut baisser sa consommation d'énergie. En effet, s'il n'y a personne à la maison, cela ne sert à rien de chauffer à 30° ! Et si on a oublié de baisser la température souhaitée de la chaufferie alors qu'on est déjà à 100 bornes, il nous suffit de se connecter à notre interface pour soit couper le chauffage, soit de baisser la température. Gain de temps, pas de dépenses énergétiques inutiles.

Autre exemple, on a oublié d'éteindre une lumière. Mon installation domotique remarque qu'une lumière est allumée mais qu'aucune personne n'est présente (merci les détecteurs de mouvements !). Alors, elle éteint la lumière pour ne pas éclairer une pièce pendant une semaine alors que vous avez les doigts de pieds en éventail à la plage à plusieurs centaines de bornes de chez vous !

Réussir à maîtriser sa consommation énergétique permet de réduire sa facture, de moins dépenser de pépètes, de pognon. Il y a bien d'autres scénarios possibles liés à la consommation énergétique. Si on se débrouille bien, on peut diviser par 2 certaines factures. A chacun son installation.

Conclusion

Cet aspect financier conclus la première partie de cet article. Il est assez long à lire, je ne voulais pas vous assommez alors que l'idée est simple : s'approprier la domotique. La deuxième partie sera en ligne dans 1 ou 2 jours. Elle abordera ma vision de l'accessibilité, le contrôle, l'automatisation et l'open source dans le domaine de la domotique. Comme d'habitude, je suis preneur de vos retours sur le sujet.

Photo by Yassine Khalfalli on Unsplash

MagicMirror², configuration scriptée, 2ème partie

Teddy Payet — 2020-04-14T22:55:42Z

Comme vous le savez tous, nous sommes en confinement depuis mi-mars. Pour m'occuper un peu en chômage partiel, en plus de ma vie de famille, je me suis inscris à une groupe d'entraide sur le MagicMirror sur Facebook. J'ai eu l'agréable surprise de voir qu'un article de mon blog était cité. Merci de la confiance de ces utilisateurs !
Après quelques échanges, j'ai proposé d'expliquer plus en détail mon installation scriptée et notamment ce à quoi correspond mes différents principaux scripts.

Tout a été déposé sur github (vous pourrez trouver le lien en bas de l'article). Je reprends ici plus ou moins le contenu du fichier Readme.

Cet article est un exemple d'automatisation de la maintenance de mon installation de MagicMirror. Le dépôt github a pour but de montrer la possibilité d'automatiser la maintenance d'une installation d'un MagicMirror.

Introduction

Le dépôt s'appelle mm_config_automate. Son existence n'est que pédagogique. Il n'est en aucun cas un module de MagicMirror.

De plus, je ne suis pas responsable d'une altération de vos données. Il vous faudra tester et adapter chaque script pour correspondre à VOS attentes.

Liste des scripts

L'ensemble des scripts sont en bash. Ils restent simples à comprendre et à prendre en main avec un peu de patience et de lecture. Voici la liste des scripts :

first_install.sh
mm_reset.sh
mm_update.sh
update_files_config.sh
disk_usage.sh

first_install.sh

Ce script permet d'installer l'ensemble des éléments de base pour qu'un MagicMirror puisse fonctionner. Il est à lancer sur une installation toute belle, toute neuve d'un Raspberry Pi 3. Je n'ai pas testé sur un Raspberry Pi 4 pour le moment. Il prend en compte un Raspbian basé sur un Debian Buster (10) mis à disposition des utilisateurs en février 2020.

Il fera dans l'ordre :

sudo apt update -y : Récupère la liste des mises à jour disponibles
sudo apt upgrade -y : Installe quelques mises à jour, ne supprime pas les packages
sudo apt autoremove -y : Supprime tous les anciens paquets qui ne sont plus nécessaires
sudo apt clean -y : Cette commande de terminal libère de l'espace disque en nettoyant les fichiers .deb téléchargés du référentiel local.

Puis :

On active le son par le HDMI ;
Forcer le HDMI ;
Forcer l'affichage vertical de l'écran ;
Enlever des programmes inutiles ;
Installation de quelques packages ;
Installation de Nodejs et NPM selon la méthode indiquée ici : https://github.com/audstanley/NodeJs-Raspberry-Pi
Ajouter les binaires de node dans le PATH ;
Installation de PM2 ;
Enregistrer les variables d'environnement (le home de MagicMirror, ainsi que de PM2) ;
Création du fichier mm.sh dans /home/pi/ ;
Exécution du script d'installation du MagicMirror ;
Sauvegarder les réglages de pm2 et lancement des scripts au démarrage ;

Et enfin, on enregistre le contenu du fichier crontab.txt dans le crontab de l'utilisateur en cours.

mm_reset.sh

Ce script installe MagicMirror à partir du dépôt github dudit projet. Il s'appelle "mm_reset" au lieu de "mm_install" car il supprime le répertoire /home/pi/MagicMirror/ s'il existe. Donc, il faut faire attention à ce point si vous désirez garder une précédente installation.

A son tour, ce script va lancer une série de commandes :

Arrêt de MM grâce à pm2 stop mm ;
Effacer le répertoire de MagicMirror si existant ;
Récupération du dépôt de MagicMirror ;
Passer sur la branche develop de MagicMirror ;
Création des liens symboliques dans MM (custom.css et config.js) ;
Installation des dépendances de MM grâce à npm ;
Lancement du script d'update des modules de MM (cf. update_files_config.sh) ;
Relancer MM sur pm2.

Liens symboliques

Dans le script mm_reset.sh, il est présumé que le fichier "config.js" et le fichier de personnalisation de css vitaux à MagicMirror soient présents dans votre répertoire /home/pi/mm_config_automate/. Un lien symbolique dans /home/pi/MagicMirror/css/ et /home/pi/MagicMirror/config/ sera fait pointant vers votre répertoire mm_config_automate.

MagicMirror n'y verra que du feu !

mm_update.sh

Ce script est plus rapide. Dans ce dépôt d'exemple, il n'est pas utilisé dans le crontab. Il est à utiliser manuellement lorsque MM doit être mis à jour.

Il arrête MM par pm2, puis va dans le répertoire de MagicMirror. A partir de là, le dépôt git est mis à jour avec les derniers fichiers. Une installation et une mise à jour des packages npm sont lancées.

Cela fait, on relance MM sur pm2.

update_files_config.sh

Ce script bash est le nerf de la guerre. Crontab appellera dans notre exemple le fichier update_files_config.sh tous les jours à 00h15.

Ce script contient 2 fonctions clés :

import_module ;
delete_modules.

Après l'utilisation de ces fonctions, une boucle est lancée pour vérifier l'existence du module MMM-AlarmClock. Ce dernier peut utiliser des fichiers mp3 comme sonnerie d'alarme.

Si vous désirez ajouter des fichiers mp3 à votre convenance, il vous suffira de les copier dans le répertoire sounds de votre dépôt "mm_config_automate". Automatiquement, tous les soirs (selon le crontab mis en place), chaque fichier mp3 présent sera copié dans /home/pi/MagicMirror/modules/MMM-AlarmClock/sounds/. Vous n'aurez plus à vous soucier d'autres choses que sa bonne utilisation dans votre fichier config.js

update_files_config.sh : fonction import_module

Cette fonction bash attend un paramètre : l'url vers le dépôt git du module que vous désirez installer sur votre MagicMirror.

Par exemple, si vous désirez utiliser le module de pages de MM, vous devez indiquer dans le fichier update_files_config.sh la commande suivante :

import_module https://github.com/edward-shen/MMM-pages.git

Elle ira dans le répertoire /home/pi/MagicMirror/modules/, vérifiera si le module existe déjà (en gros l'existence du répertoire "MMM-pages") ou pas. S'il n'existe pas, elle clonera le répertoire. Puis :

Accéder au répertoire du module ;
Si un fichier package.json existe, l'installation des packages npm est lancée.

Il faudra utiliser cette fonction autant de fois que de modules désirés. Vous trouverez des exemples dans ledit fichier.
Cerise sur le gateau, si le module existe déjà, il le mettra à jour avec les derniers fichiers provenant du dépôt que vous avez indiqué en paramètre.

update_files_config.sh : fonction delete_modules

Cette fonction se lance après l'ensemble des appels à import_module. Elle a pour but de supprimer les modules présents dans /home/pi/MagicMirror/modules/ devenus obsolètes.

Comme vous le savez, pour utiliser un module dans MagicMirror, nous devons l'avoir téléchargé d'une part dans /home/pi/MagicMirror/modules/ mais d'autre part l'avoir indiqué dans notre fichier config.js.

Si le répertoire /home/pi/MagicMirror/modules/nom_repertoire/ n'est pas indiqué dans ce fichier, le répertoire sera considéré comme obsolète. Donc, qu'il peut être supprimé. La présente fonction vérifiera chaque répertoire dans modules/ à l'exclusion de :

default/
node_modules/

Cela préservera l'espace disque de votre Raspberry Pi et évitera des erreurs dans votre MagicMirror.

disk_usage.sh

Ce script permet de savoir le pourcentage d'utilisation d'espace disque. Dans le présent exemple, si le taux d'utilisation arrive à 90% de sa capacité, un email est envoyé (je vous laisse le soin de configurer le serveur d'envoi d'emails).

Il faut savoir que pm2 écrit beaucoup d'information dans les logs (cela dépend surtout des applications lancées sous pm2 mais c'est un autre sujet). En prenant cela en compte, si le taux d'utilisation excède les 90%, le script lance en premier lieu la commande pm2 flush pour vider l'ensemble des fichiers logs de pm2. Puis vérifie à nouveau le taux de remplissage. Si la commande n'a pas changé la donne, l'email est envoyé.

crontab.txt

Ce petit bout de fichier vous permet d'indiquer l'heure à laquelle vos routines doivent être mises en place.

Dans le présent exemple, voici les routines :

A 0h00 : On vérifie d'abord l'espace disque
A 0h05 : On met à jour les fichiers de mm_config_automate
A 0h10 : On importe le contenu du fichier crontab.txt dans le crontab à 00h10
A 0h15 : On peut maintenant lancer les scripts de routine (update_files_config.sh)
A 0h20 : On relance MagicMirror pour prendre en compte la configuration à jour.
Tous les mois, on redémarre le Raspberry Pi

Si vous êtes parents et/ou assujetti à des périodes de vacances et un planning différents durant ces périodes, il est possible de mettre en place un fichier de config dédié à cette période.

Dans notre exemple, le contenu de config.js et config_vac.js sont identiques. Le but est d'illustrer l'existence des fichiers selon la période. En ayant en tête les dates de vacances qui vous intéressent, vous pouvez ajouter une ligne dédiée dans crontab pour que le lien symbolique de /home/pi/MagicMirror/config/config.js pointe vers le fichier /home/pi/mm_config_automate/config_vac.js au lieu de /home/pi/mm_config_automate/config.js. Le jour où vous devez revenir au travail (donc la fin de votre période de vacances) à 00h30, il suffira de remettre le lien symbolique vers /home/pi/mm_config_automate/config.js

Exemple pour les vacances de l'Ascension de la zone C :

############### # Vacances Ascension : 20 mai 30 0 20 5 0 cd /home/pi/MagicMirror/config/; rm -rf config.js; ln -s /home/pi/mm_config_automate/config_vac.js config.js; pm2 restart mm # Rentrée : 25 mai 30 0 25 5 * cd /home/pi/MagicMirror/config/; rm -rf config.js; ln -s /home/pi/mm_config_automate/config.js config.js; pm2 restart mm

Voilà. A vous de prendre en main ce projet en le copiant dans un dépôt personnel privé et de le faire vivre.

Le projet sur github

Comme indiqué en début de cet article, les différents fichiers ont été déposé sur github. Ils ont pour but de vous aider à mettre en place votre automatisation :
https://github.com/Ybbet/mm_config_automate

Attention de ne pas mettre le projet en public si vous l'utiliser sur VOTRE installation. Préservez votre vie... privée.

A lire aussi

Des astuces et mémos pour SVN

Teddy Payet — 2018-06-15T09:00:00Z

Je travaille encore très souvent sur des projets sous SVN avec grand plaisir. J'utilise des lignes de commandes pour aller plus vite. Il arrive parfois que je me creuse les méninges pour certaines lignes de commandes. Alors, un petit article mémo ne fera pas de mal.

Lorsqu'on est sous SVN, il est parfois utile de voir la liste des éléments qui ne sont pas encore reconnus dans le dépôt.

svn st | grep ^?

Et si on ne veut pas avoir le " ?" et les espaces entre ce " ?" et le nom des éléments :

svn st | grep ^? | cut -c9-

Pour lister tous les éléments qui ont été modifié :

svn st | grep ^M

Pour lister tous les éléments qui ont été ajouté :

svn st | grep ^A

Pour lister tous les éléments qui sont introuvables :

svn st | grep ^!

Si vous désirez afficher tous les éléments autres que modifiés ou ajoutés :

svn st | grep -v ^[AM]

Afficher tous les fichiers ayant été modifié, ou ajouté ou qui ne sont pas reconnus par svn :

svn st | grep ^[AMD\!?]

Il arrive parfois qu'on ait besoin de déposer des fichiers (exemple : un dump d'une base de données) mais sans vouloir télécharger tout le répertoire cible sur son local. Voici la commande adéquate :

svn co http://example.org/url_depot/bdd_dump/ --depth empty

Cela permettra de faire un checkout sur son local sans télécharger tous les fichiers présents sur le dépôt.

Règle générique

De manière générale, SVN en lignes de commande ajoute 9 caractères avant le nom de l'élément affiché. De ce fait, à chaque fois que vous ne désirez pas voir ces 9 caractères (ou 9 colonnes), il faut mettre à la fin de votre commande | cut -c9-

En bash, si on désire exporter le résultat de notre commande dans un fichier, il faut rajouter à la fin de notre commande " > nom_fichier.txt"
Soit pour exemple, la liste des fichiers autres que modifiés et/ou ajoutés :

svn st | grep -v ^[AM] > files.txt

Ajouter de nouveaux fichiers/répertoires au dépôt

for new_element in $(svn st | grep "^?" | cut -c9-); do svn add ${new_element}; done;

Supprimer des fichiers/répertoires obsolètes au dépôt

for delete_element in $(svn st | grep "^\!" | cut -c9-); do svn delete ${delete_element}; done;

Visuel : Photo by Moja Msanii on Unsplash

MagicMirror², on recommence depuis le début

Teddy Payet — 2018-06-08T05:30:00Z

Récemment, j'ai écrit un article pour installer mon MagicMirror². Ce tutoriel est tout à fait fonctionnel. Malheureusement, pas dans mon cas car j'avais des versions de packages trop anciennes (cf. node.js). Je vais vous expliquer comment j'ai remédié à cela. :-)

J'ai acheté mon Raspberry Pi en juin 2016. J'en avais fait l'acquisition pour tester Gladys. A cette période, la version 2 de Gladys sortait des cartons et avaient peu de plugins pour agrémenter le tout.
Je l'ai donc laissé un peu de côté en attendant le bon moment pour réaliser mon deuxième projet pour ce petit bijoux.

Incompatibilité

J'avais installé toutes les librairies nécessaires pour Gladys et elle-même également. Or, ces versions sont conflictuelles avec ce que MagicMirror² désire. Je vais être honnête, ça me prendrait plus de temps de désinstaller chaque composant plutôt que de refaire la carte SD à partir de l'image de Raspbian fourni par raspberry.org.

Recommençons

Le premier point est de refaire la carte SD avec l'image 2018-04-18-raspbian-stretch issue du site officiel. Cela aura pour effet de repartir de zéro.

Cela fait, on remet la carte SD dans le Raspberry PI pour un redémarrage. Ce dernier point se passe quand même rapidement. Il n'y a pratiquement rien à faire. Les choses sont bien ficelées.

Installation de packages

Il est nécessaire d'installer quelques petits packages pour assurer leur disponibilité au moment voulu :

sudo apt-get install git zip unzip curl wget

Oui, ce n'est pas vraiment nécessaire avec une installation fraîche. Toutefois, cette action permettra de mettre tout le monde au même niveau.

Mise à jour des packages

Comme dans le précédent tutoriel, j'ai mis à jour les packages et le firmware :

sudo apt-get update; sudo apt-get upgrade; sudo apt-get autoremove; sudo rpi-update; sudo apt-get clean

A la fin de cette ligne, je vide le cache puis un redémarrage : sudo reboot

Installation de Node et MagicMirror²

Le redémarrage étant fait, on va maintenant lancer les scripts initiaux :
Node.js

wget -O - https://raw.githubusercontent.com/audstanley/NodeJs-Raspberry-Pi/master/Install-Node.sh | sudo bash node -v

MagicMirror²

bash -c "$(curl -sL https://raw.githubusercontent.com/MichMich/MagicMirror/master/installers/raspberry.sh)"

J'ai vu qu'une branche develop était présente et des commits sur cette branche réglaient quelques bugs. Alors, je passe à cette branche :

cd ~/MagicMirror/ git checkout -b develop git pull

Après cela, on peut lancer l'installation :

npm install

Tout s'est bien passé pour mon installation. Cool.

Installation des modules

Pour mes besoins actuels, j'utilise les modules suivants :

Le principe d'installation est le même pour tous les modules :

cd ~/MagicMirror/modules/ git clone https://github.com/user/mmm-nom-module

Soit :

cd ~/MagicMirror/modules/ git clone https://github.com/tataille/MMM-FreeBox-Monitor.git git clone https://github.com/spectroman/mmm-moon-phases.git git clone https://github.com/edward-shen/MMM-page-indicator.git git clone https://github.com/edward-shen/MMM-pages.git

Pour le reste, la configuration des modules se fait dans le fichier ~/MagicMirror/config/config.js

Configuration du fichier config.js

Comme le demande la documentation de MagicMirror², on doit copier ~/MagicMirror/config/config.js.sample vers ~/MagicMirror/config/config.js
Cela dit… Je ne vais pas faire ça. :-D

En effet, je vais faire en sorte d'avoir une version du fichier config.js qui soit versionnée sur un git.
Comme tout projet git, il n'est pas possible de cibler sur un fichier purement et simplement (comme le ferait svn par exemple). De ce fait, j'ai créé sur Gitlab.com un projet qui sera en mode privé.

On peut nommer ce projet "magicmirror_config" pour faire simple.
Depuis le terminal, je tape les lignes suivantes :

cd ~/ git clone https://gitlab.com/user/magicmirror_config.git

Maintenant, je crée un lien symbolique dans ~/MagicMirror/config/ pointant vers ~/magicmirror_config/config.js

cd ~/MagicMirror/config/ mv config.js config.js.old ln -s ~/magicmirror_config/config.js config.js

Par la même occasion, j'ai fait la même chose avec le fichier ~/MagicMirror/css/custom.css. Pratique pour personnaliser son affichage graphiquement.

cd ~/MagicMirror/css/ mv custom.css custom.css.old ln -s ~/magicmirror_config/custom.css custom.css

Démarrage automatique de MagicMirror²

Comme indiqué dans https://github.com/MichMich/MagicMirror/wiki/Auto-Starting-MagicMirror, il est possible de lancer automatiquement MagicMirror² au démarrage. Pour cela, il est nécessaire d'installer PM2 sur la machine.
Le script d'installation de MagicMirror² le fait. Mais j'ai eu un souci que je ne saurais identifier pour le moment. Je verrai cela plus tard.

Le script a bien installé pm2 mais n'a pas fait les liens symboliques pour ce stretch. Cela se trouve dans /opt/nodejs/bin/.
Sur stretch, on fait un lien vers /etc/alternatives/ puis de là, un lien dans /usr/bin/.
Voici le code à taper dans Terminal :

sudo ln -s /opt/nodejs/bin/pm2 /etc/alternatives/pm2 sudo ln -s /etc/alternatives/pm2 /usr/bin/pm2 sudo ln -s /opt/nodejs/bin/pm2-dev /etc/alternatives/pm2-dev sudo ln -s /etc/alternatives/pm2-dev /usr/bin/pm2-dev sudo ln -s /opt/nodejs/bin/pm2-docker /etc/alternatives/pm2-docker sudo ln -s /etc/alternatives/pm2-docker /usr/bin/pm2-docker sudo ln -s /opt/nodejs/bin/pm2-runtime /etc/alternatives/pm2-runtime sudo ln -s /etc/alternatives/pm2-runtime /usr/bin/pm2-runtime

Créer un fichier de démarrage de MagicMirror²
Pour nous simplifier la tâche, il est conseillé de créer un fichier bash :

cd ~ nano mm.sh

Puis d'ajouter les lignes suivantes :

cd ~/MagicMirror DISPLAY=:0 npm start

On enregistre le tout. Puis on le rend exécutable.

chmod +x mm.sh

Démarrer MagicMirror² avec PM2

C'est vraiment tout simple :

pm2 start mm.sh

Activer le démarrage du script
On doit être sûr que le script soit lancé au démarrage. Pour cela, on sauvegarde les réglages actuels de PM2 :

pm2 save

Contrôler son MagicMirror² via PM2

Avec MagicMirror fonctionnant via PM2, on dispose d'outils pratiques :

Redémarrer MagicMirror

pm2 restart mm

Arrêter MagicMirror

pm2 stop mm

Afficher les logs MagicMirror

pm2 logs mm

Afficher les informations sur le processus MagicMirror

pm2 show mm