Teddy Payet

Les projets numériques ne vieillissent pas comme on l'imagine

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

Les projets numériques ne s'usent pas comme des outils. Ils se transforment avec le temps, par couches successives, décisions implicites et compromis accumulés. Cet article propose un regard sur ce que le temps révèle vraiment : ce qu'il met à l'épreuve, ce qu'il exige, et ce qui permet à un projet de durer sans se renier.

Préambule

Les projets numériques sont souvent pensés pour démarrer. Rarement pour durer.

Au lancement, tout semble clair. Les objectifs sont identifiés. Les choix paraissent cohérents. Les compromis acceptables. Le projet avance, porté par l'élan, par l'urgence parfois, par l'enthousiasme souvent.

Puis le temps passe.

Ce temps n'est pas brutal. Il n'annonce rien. Il s'installe doucement. Il accumule des décisions, des ajustements, des non-décisions aussi. Le projet continue de fonctionner, parfois très bien, mais il change de nature. Ce qui était simple devient implicite. Ce qui était évident cesse de l'être.

On imagine souvent que les projets vieillissent comme des outils. Qu'ils s'usent, qu'ils deviennent obsolètes, qu'il suffirait de les remplacer ou de les refondre. En réalité, ils vieillissent plutôt comme des organisations. Par couches successives. Par habitudes prises. Par équilibres qui se figent sans qu'on s'en rende compte.

Avec le recul, ce ne sont pas les choix initiaux qui posent le plus de problèmes. Ce sont ceux que l'on n'a pas formalisés. Ceux que l'on a laissés au temps. Et que le temps, justement, a transformés.

Cet article ne cherche pas à expliquer comment faire durer un projet. Il propose plutôt un regard sur ce que le temps révèle. Sur ce qu'il met à l'épreuve. Et sur ce qu'il oblige, tôt ou tard, à regarder en face.

Ce que le lancement ne montre jamais

Un lancement montre surtout ce qui est visible. Les fonctionnalités principales. Les parcours attendus. Les choix assumés à un instant donné. Il donne une impression de cohérence, parfois même de maîtrise.

Ce qu'il ne montre pas, ce sont les renoncements. Les simplifications nécessaires. Les décisions prises vite, parce qu'il fallait avancer. Ces choix sont rarement mauvais. Ils sont simplement contextuels. Et ce contexte, avec le temps, disparaît.

Au démarrage, tout semble encore malléable. Les règles ne sont pas figées. Les usages restent à inventer. Le projet est léger, presque souple. Cette souplesse est précieuse. Elle permet d'avancer. Elle permet aussi de reporter certaines questions.

Mais le lancement masque une réalité plus discrète : chaque décision, même mineure, commence déjà à orienter le projet. À structurer ses données. À façonner ses usages. À créer des habitudes qui, plus tard, seront difficiles à remettre en cause.

Ce que le lancement ne montre jamais, c'est la trace que ces choix laisseront. Non pas immédiatement, mais dans la durée. Quand le projet aura grandi. Quand d'autres personnes s'en seront emparées. Quand les contraintes auront changé.

Le temps ne juge pas ces décisions. Il les amplifie simplement.

Ce que le temps accumule

Avec le temps, un projet ne change pas par rupture. Il se transforme par superposition. Des couches successives viennent s'ajouter, rarement remises en question, souvent jugées acceptables sur le moment.

Il y a d'abord les décisions implicites. Celles qui n'ont jamais été formalisées parce qu'elles semblaient évidentes. Elles deviennent des règles sans statut, connues de quelques-uns, transmises par habitude plutôt que par choix.

Puis viennent les compromis. Acceptés pour tenir un délai. Pour répondre à une contrainte ponctuelle. Pour satisfaire un besoin urgent. Pris isolément, ils sont rationnels. Accumulés, ils modifient en profondeur l'équilibre du projet.

Le temps ajoute aussi des dépendances. Techniques, organisationnelles, humaines. Des éléments qui n'étaient pas centraux au départ prennent de l'importance. D'autres deviennent intouchables, non parce qu'ils sont essentiels, mais parce que plus personne ne sait vraiment ce qu'il se passerait si on les modifiait.

Ces couches ne sont pas visibles au quotidien. Le projet continue de fonctionner. Il répond encore aux attentes. C'est précisément ce qui rend cette accumulation silencieuse. Rien ne casse. Rien n'alerte franchement. Peu à peu, le projet cesse d'être un ensemble cohérent pensé comme tel. Il devient le résultat d'une histoire. Une histoire faite d'ajouts, d'adaptations et de contournements. Le temps n'a pas créé de problèmes nouveaux. Il a simplement rendu permanents des choix temporaires.

Ce que le temps met à l'épreuve

Avec le temps, ce ne sont pas seulement les choix initiaux qui sont testés. Ce sont les cadres qui les entouraient. La manière dont les décisions étaient prises. Dont elles étaient expliquées. Dont elles étaient partagées.

La gouvernance est souvent la première mise à l'épreuve.
Au début, les rôles sont clairs, ou du moins identifiés. Puis les contours s'estompent. Les décisions deviennent plus diffuses. Certaines sont prises par habitude, d'autres par défaut. Le projet continue d'avancer, mais le pilotage perd en lisibilité.

Vient ensuite la question de la transmission. Ce qui n'a pas été formalisé finit par se perdre. Les raisons d'un choix, le contexte d'un arbitrage, les limites acceptées à un moment donné disparaissent avec le temps. De nouvelles personnes arrivent. Elles héritent d'un système fonctionnel, mais dont l'histoire est incomplète.

Le temps met également à l'épreuve la capacité à décider encore. Quand chaque évolution semble risquée, la décision devient un exercice délicat. On hésite. On contourne. On repousse. Non par manque de compétence, mais parce que les marges de manœuvre se sont réduites sans que cela ait été réellement anticipé.

Dans ces conditions, le projet peut continuer à fonctionner tout en perdant sa dynamique. Les décisions ne sont plus guidées par une vision, mais par la peur de déséquilibrer un ensemble devenu fragile. Le temps n'a pas créé cette fragilité. Il l'a révélée.

Ce que le temps met à l'épreuve, ce n'est pas la solidité technique d'un projet. C'est sa capacité à rester pilotable.

Ce que le temps exige

Le temps ne demande pas des réponses spectaculaires. Il exige autre chose. De la constance. De la lucidité. Et une capacité à revenir régulièrement sur ce qui semblait acquis.

Un projet qui dure demande d'être entretenu, pas seulement utilisé. Non pour tout remettre en cause, mais pour vérifier que les équilibres tiennent encore. Que les choix passés restent pertinents. Et que ceux qui n'avaient jamais été formalisés méritent, enfin, de l'être.

Le temps exige aussi de la clarté. Nommer les règles, expliciter les décisions, assumer les renoncements. Ce travail est rarement visible. Il n'apporte pas de nouveauté immédiate. Mais il évite que le projet ne dérive silencieusement, jusqu'au point où plus personne ne sait vraiment ce qui peut encore évoluer.

Il impose également une forme d'humilité. Accepter que tout ne puisse pas être conservé. Certaines solutions doivent être simplifiées. D'autres abandonnées. Non parce qu'elles étaient mauvaises, mais parce qu'elles ne correspondent plus au projet tel qu'il est devenu.

Enfin, le temps exige des choix assumés. Pas seulement quand tout va mal, mais précisément quand tout semble encore fonctionner. C'est dans ces moments-là que les décisions sont les plus structurantes, parce qu'elles ne sont pas dictées par l'urgence.

Ce que le temps attend d'un projet n'est pas la perfection. Il attend une capacité à se regarder avec honnêteté, à ajuster sa trajectoire, et à accepter que durer implique parfois de changer.

Pour conclure

Le temps n'est pas un simple paramètre des projets numériques. Il en est la matière première invisible. Celui qui révèle ce qui tient, ce qui s'effrite, et ce qui n'a jamais vraiment été pensé pour durer.

Un projet ne se juge pas à son lancement, ni à sa première réussite. Il se mesure à sa capacité à traverser les années sans se renier, à évoluer sans se perdre, à accueillir le changement sans se disloquer. Ce que le temps éprouve, ce ne sont pas les outils, ni même les choix initiaux. Ce sont les intentions, les cadres et le courage de les revisiter.

Les projets numériques ne vieillissent pas comme on l'imagine parce qu'ils ne s'usent pas mécaniquement. Ils racontent une histoire. Celle des décisions assumées. Des renoncements différés. Des compromis accumulés. Et parfois, de l'absence de regard porté sur ce qu'ils sont devenus.

Durer n'est jamais un accident. C'est une discipline. Une attention constante. Une capacité à accepter que ce qui a fonctionné hier ne suffira pas demain. Et surtout, une volonté de ne pas laisser le temps décider à la place de celles et ceux qui portent le projet.

Le temps ne détruit pas les projets numériques.
Il les met à nu.

Et ce qu'il révèle alors n'est pas une question de technologie, mais de lucidité, de responsabilité et de vision.

Photo de David Lusvardi sur Unsplash

Pourquoi l'expertise technique ne suffit pas

Teddy Payet — 2026-01-20T07:30:00Z

L'expertise technique est souvent réduite à un rôle d'exécution. Pourtant, avec le temps, elle devient un levier essentiel pour comprendre le produit, éclairer les choix et assumer les arbitrages.

Cet article explore ce moment de bascule où la technique cesse d'être une réponse pour devenir un outil stratégique au service du produit et de ses décisions.

Préambule

Dès que l'on parle de technique, le débat se referme souvent trop vite. On suppose une discussion d'implémentation, de solutions, de faisabilité au sens étroit. Et dès que l'on évoque une “fonction”, on entend parfois que l'on ramène la conversation sur un terrain technique.

Ce raccourci est révélateur d'un malentendu plus profond.

Parler de fonction n'est pas parler de code. Ce n'est pas proposer une solution déguisée. C'est chercher à comprendre un besoin, à en préciser l'intention, à en mesurer la portée. C'est interroger ce que le produit doit réellement faire, pour qui, et dans quel cadre.

Avec l'expérience, l'expertise technique cesse d'être uniquement un savoir-faire. Elle devient un langage commun. Un moyen de relier le besoin métier à la réalité du produit, à sa structure, à ses données, à ses usages existants. Sans cette lecture globale, la technique reste performante, mais aveugle. C'est souvent à ce moment-là que l'incompréhension apparaît. Non parce que la technique prend trop de place, mais parce qu'elle cesse d'être exécutante. Elle questionne le besoin. Elle clarifie les attentes. Elle met en lumière les arbitrages implicites.

Cet article part de là. De ce point précis où l'expertise technique, indispensable, ne suffit plus à elle seule. Et où elle commence à jouer un rôle différent : aider à comprendre le produit, à cadrer les choix, et à décider ce qui est réellement pertinent, avant même de se demander comment le réaliser.

La confusion entre technique et exécution

Dans beaucoup de projets, la technique est encore perçue comme une affaire d'exécution. Elle serait là pour répondre à une demande, implémenter une solution, produire ce qui a été décidé ailleurs. Dans ce cadre, elle intervient tard, une fois le besoin supposé clair.

Cette lecture est réductrice. Elle enferme l'expertise technique dans un rôle d'opérateur, alors qu'elle pourrait jouer un rôle bien plus structurant en amont. Dès que la technique sort de ce périmètre et commence à poser des questions, elle est souvent perçue comme un obstacle.

C'est particulièrement visible lorsqu'on parle de “fonction”. Le terme est vite associé à une implémentation, à une solution déguisée. Comme si interroger une fonction revenait nécessairement à imposer une réponse technique. En réalité, c'est souvent l'inverse.

Parler de fonction, c'est parler de produit. C'est questionner ce que le produit fait aujourd'hui, ce qu'il promet, et ce qu'il ne doit pas devenir. C'est comprendre comment les données sont structurées, comment les usages se sont construits, et où se situent les véritables points de fragilité.

Lorsque cette confusion persiste, le débat se déplace. On discute de faisabilité avant de discuter de pertinence. On cherche des solutions avant d'avoir clarifié le besoin. Et la technique se retrouve à encaisser des décisions qui n'ont pas été réellement posées.

Réduire l'expertise technique à l'exécution, c'est se priver d'un outil de compréhension du produit.

C'est aussi préparer des incompréhensions futures, lorsque les limites apparaîtront non comme des choix assumés, mais comme des contraintes subies.

Quand parler de fonction, c'est parler de stratégie

Une fonction n'est jamais anodine.

Elle n'est pas une ligne dans un backlog, ni une simple demande à exécuter. Elle porte une intention. Une vision implicite du produit. Une manière de répondre à un besoin métier, parfois clairement formulé, parfois encore flou.

Parler de fonction, c'est d'abord chercher à comprendre ce besoin. À distinguer ce qui est attendu de ce qui est réellement nécessaire. À faire émerger les usages derrière la demande. Cette étape est rarement spectaculaire. Elle est pourtant décisive.

Très souvent, la question n'est pas de savoir comment réaliser une fonction, mais si elle doit exister, à quel moment, et dans quel cadre. Ce sont des choix structurants, bien avant toute implémentation.

C'est là que l'expertise technique change de rôle.

Elle ne sert plus à produire une solution. Elle sert à éclairer des options. À montrer ce que cette fonction implique pour le produit, pour ses données, pour ses équilibres existants. Elle permet de dire “oui”, “non”, ou “pas comme ça”. Et surtout, d'expliquer pourquoi.

À ce stade, parler de fonction n'est déjà plus un sujet technique. C'est un sujet de trajectoire. Une fonction oriente le produit. Elle crée des dépendances. Elle fige parfois des usages pour longtemps. Ne pas la questionner, c'est décider sans le savoir.

La stratégie d'un produit se construit souvent dans ces discussions discrètes, bien avant que le code n'existe.

Lorsque cette dimension est comprise, le débat change de nature. On ne cherche plus la meilleure solution. On cherche la décision la plus juste, au regard du métier, du produit et de son avenir.

Le rôle stratégique de l'expertise technique

À ce stade, l'expertise technique ne consiste plus à répondre par une solution. Elle consiste à rendre les choix lisibles.

Elle permet de transformer une intention floue en options concrètes. D'expliquer ce que chaque option implique, non seulement en termes de réalisation, mais aussi pour le produit lui-même. Pour ses données. Pour ses usages existants. Pour ce qu'il deviendra une fois la décision prise.

Ce rôle est souvent mal identifié, parce qu'il est discret. Il ne produit pas immédiatement de livrable. Il ralentit parfois le rythme apparent du projet. Mais il évite surtout des trajectoires irréversibles, prises trop vite.

L'expertise technique stratégique n'impose pas une réponse. Elle cadre le champ des possibles. Elle met en évidence les conséquences. Elle rend explicites des choix qui, sans cela, resteraient implicites et donc difficiles à assumer par la suite.

Dans cette posture, dire “ce n'est pas réalisable” n'est pas un refus. Dire “c'est réalisable, mais à ce prix-là” n'est pas un frein. Et dire “on peut le faire autrement” n'est pas une remise en cause du besoin. C'est une aide à la décision.

L'expertise technique devient alors un outil d'arbitrage, pas un simple moyen d'exécution. C'est précisément à ce moment-là qu'elle dépasse le cadre du développement. Elle participe à la construction du produit, à sa cohérence et à sa trajectoire. Et c'est aussi là qu'elle cesse de suffire seule, car elle doit désormais s'inscrire dans un cadre collectif de décision.

Pourquoi ce rôle est souvent mal compris

Ce rôle stratégique de l'expertise technique arrive souvent à un moment délicat du projet. Celui où l'on ne peut plus se contenter d'exécuter, mais où il devient nécessaire de choisir. Et choisir implique d'assumer des arbitrages, parfois inconfortables.

Dans beaucoup de contextes, on attend encore de la technique qu'elle rassure. Qu'elle confirme qu'une demande est faisable. Qu'elle apporte une réponse rapide, presque immédiate. Lorsqu'elle commence à questionner le besoin, à demander des précisions, ou à évoquer des conséquences à moyen terme, elle change de registre. Et ce changement est parfois mal perçu. Ce décalage n'est pas forcément conflictuel. Il est souvent lié à la pression du temps, aux contraintes budgétaires, ou à une volonté sincère d'avancer. Dans ces conditions, toute mise en perspective peut donner l'impression de ralentir le projet, voire de le compliquer inutilement.

Pourtant, ce qui se joue là n'est pas un désaccord technique. C'est un moment de clarification. L'expertise met en lumière des décisions qui, jusque-là, étaient implicites. Elle oblige à formuler des choix qui n'avaient pas encore été posés. Non pas pour bloquer, mais pour éviter que ces choix ne soient faits par défaut, plus tard, dans un contexte moins maîtrisé.

Lorsque la technique parle de structure, de données ou de cohérence produit, elle ne cherche pas à reprendre la main. Elle cherche à éviter que le projet dérive sans que personne n'en ait réellement conscience. Ce déplacement du débat peut être déstabilisant, mais il est souvent salutaire.

C'est précisément à ce stade que l'expertise technique cesse d'être confortable. Elle n'apporte plus uniquement des solutions. Elle invite à regarder le produit tel qu'il est, avec ses limites, ses contraintes et ses conséquences possibles. Et cela demande, de part et d'autre, une certaine maturité collective.

Quand l'expertise devient responsabilité produit

Avec le temps, cette posture s'impose presque naturellement. L'expertise technique ne se limite plus à analyser des solutions ou à en mesurer la faisabilité. Elle s'élargit à une responsabilité plus globale : celle de la cohérence du produit dans la durée.

Cela suppose une connaissance fine de ce que le produit est devenu. De sa structure de données. De ses usages réels, parfois éloignés de ce qui avait été imaginé au départ. De ses dépendances aussi, techniques ou fonctionnelles. Sans cette lecture, les décisions restent partielles.

À ce stade, l'expertise technique rejoint une logique de pilotage produit. Non pas pour se substituer aux autres rôles, mais pour les éclairer. Elle aide à comprendre ce qui peut évoluer sans risque, ce qui demande des précautions, et ce qui ne devrait pas être remis en cause sans une réflexion approfondie.

Cette responsabilité implique aussi d'accepter des renoncements. Dire qu'une demande est pertinente, mais pas maintenant. Qu'une évolution est souhaitable, mais incompatible avec l'état actuel du produit. Ou qu'une solution séduisante créerait plus de fragilité qu'elle n'apporterait de valeur. Ce déplacement peut être déroutant. Il l'est parfois pour ceux qui attendent encore de la technique qu'elle fournisse des réponses immédiates. Mais il est essentiel pour éviter que le produit ne se construise par accumulation, sans vision d'ensemble.

À ce niveau, l'expertise ne cherche plus à démontrer sa maîtrise. Elle cherche à préserver l'équilibre du produit. À faire en sorte que chaque décision s'inscrive dans une trajectoire compréhensible, assumée, et soutenable dans le temps.

Conclusion

L'expertise technique reste indispensable. Elle fonde la crédibilité, la compréhension des contraintes et la qualité des choix possibles. Mais à elle seule, elle ne suffit pas à faire durer un projet.

À mesure que les produits se complexifient et que les enjeux s'élargissent, l'expertise change de rôle. Elle cesse d'être uniquement un savoir-faire d'exécution pour devenir un outil de compréhension, de cadrage et de décision. Elle n'apporte plus seulement des solutions, elle aide à poser les bonnes questions.

Ce déplacement n'est ni une remise en cause, ni une évolution hiérarchique. C'est une transformation naturelle, dictée par la réalité des projets. Là où la technique éclaire le produit, structure les arbitrages et rend les choix assumables dans le temps.

C'est souvent à cet endroit précis que les projets tiennent ou se fragilisent. Non pas faute de compétence, mais faute d'une expertise capable de dépasser le “comment” pour interroger le “pourquoi”.

L'expertise technique ne suffit pas.
Mais mise au service du produit et de ses décisions, elle devient essentielle.

Photo de Sasha Kaunas sur Unsplash

La maintenance SPIP n'est pas un coût : c'est une stratégie

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

La maintenance est souvent traitée comme une contrainte technique. En réalité, elle relève d'un choix de pilotage. Cet article propose un regard stratégique sur la maintenance des projets SPIP, non comme un coût à subir, mais comme une condition essentielle pour décider, arbitrer et faire durer un produit numérique sans que la technique ne devienne un alibi.

Préambule

La maintenance est rarement prioritaire. Tant que le site fonctionne, elle reste en arrière-plan. Elle ne produit rien de visible, n'apporte pas de nouveauté immédiate, et se confond souvent avec une contrainte à repousser.

Pourtant, dans un projet SPIP, la maintenance n'est pas un détail technique. C'est un choix structurant. Un choix qui conditionne la capacité à évoluer, à corriger, à décider sans urgence.

Pendant longtemps, maintenir un site consistait surtout à faire tenir l'existant. Aujourd'hui, les attentes ont changé. Les projets s'inscrivent dans la durée. Les environnements évoluent. Les usages aussi. La maintenance ne peut plus être pensée comme une opération ponctuelle.

Une approche moderne de la maintenance ne consiste pas à tout gérer soi-même. Elle repose au contraire sur une séparation claire. Le cœur de SPIP n'est pas le produit. Les plugins communautaires non plus. Ce qui compte, c'est ce qui fait la valeur du site, son usage, son métier.

Maintenir, ce n'est pas entretenir le passé. C'est organiser l'avenir du projet. C'est dans cette perspective que la maintenance cesse d'être un coût. Elle devient une stratégie. Une manière de rester concentré sur l'essentiel, sans subir la technique, ni la laisser décider à notre place.

Pourquoi la maintenance est encore perçue comme un coût

La maintenance ne se voit pas. Quand elle est bien faite, rien ne change en apparence. Le site fonctionne, les contenus s'affichent, les utilisateurs ne remarquent rien de particulier.

C'est précisément pour cela qu'elle est souvent reléguée au second plan. Elle ne produit pas de fonctionnalités, ne s'accompagne pas d'un livrable visible, et s'inscrit rarement dans un calendrier de communication. Dans beaucoup de projets, la maintenance est confondue avec du support. Elle est associée à la correction, à l'incident, à l'urgence. Jamais à la construction. Jamais à la stratégie.

Ce qui fonctionne n'attire jamais l'attention. Tant que le site tient, la maintenance semble facultative. Et le jour où elle devient indispensable, il est souvent déjà trop tard pour la penser sereinement.

Quand la maintenance devient moderne

La maintenance moderne n'est pas une invention récente. D'autres technologies l'ont intégrée depuis longtemps. Elles ont compris qu'un projet ne devait pas reposer sur la gestion manuelle de chaque composant, mais sur des dépendances clairement identifiées et des processus reproductibles.
Cette approche a fait ses preuves. Elle permet de savoir ce qui est utilisé, dans quelle version, et dans quel cadre. Elle réduit les manipulations hasardeuses. Elle limite les écarts entre les environnements. Et surtout, elle rend les projets compréhensibles par d'autres que ceux qui les ont initialement mis en place.

Appliquer cette logique à SPIP change profondément la manière de penser la maintenance. Le cœur du système et les extensions ne sont plus des éléments que l'on modifie directement. Ils deviennent des briques maîtrisées, intégrées dans un cadre clair. Ce n'est pas une contrainte supplémentaire. C'est une simplification.

La maintenance cesse alors d'être une succession d'actions isolées. Elle devient un processus continu, prévisible, documentable. Un socle sur lequel le projet peut évoluer sans repartir de zéro à chaque étape.

Ce qui fonctionne ailleurs depuis longtemps fonctionne aussi ici, dès lors qu'on accepte de changer de posture. En adoptant ces méthodes éprouvées, on ne cherche pas à rendre SPIP plus complexe. On cherche au contraire à le rendre plus lisible, plus durable, et plus cohérent avec les attentes actuelles des projets numériques.

Se libérer de ce qui n'est pas le cœur du projet

Dans un projet SPIP, tout n'a pas la même valeur stratégique. Pourtant, beaucoup de temps et d'énergie sont souvent consacrés à des éléments qui ne font pas la spécificité du site. Le socle technique, les briques communes, les extensions génériques finissent par occuper une place disproportionnée dans les décisions.

Ce glissement est insidieux. À force de tout considérer comme critique, plus rien ne l'est vraiment. Le pilotage se brouille. Les discussions portent sur la mécanique plutôt que sur la finalité. Le projet avance, mais son centre de gravité se déplace.

Se libérer de ce qui n'est pas le cœur du projet, ce n'est pas se désengager. C'est clarifier. Accepter que certains composants relèvent d'un cadre maîtrisé, stable et partagé, afin de concentrer l'attention là où elle est réellement nécessaire. Sur le produit numérique. Sur les usages. Sur le métier.

À partir de ce moment-là, la maintenance change de nature. Elle n'est plus une accumulation de tâches techniques. Elle devient un outil de pilotage. Un moyen de protéger ce qui fait la valeur du projet, en évitant qu'il soit noyé dans des arbitrages de bas niveau. Maintenir, c'est choisir où l'on met son énergie et sa responsabilité.

Cette clarification est décisive. Elle conditionne la capacité à discuter des évolutions, à prioriser, et à décider sans que chaque sujet technique ne devienne un frein ou un prétexte à l'inaction.

Maintenir, c'est rester en capacité de décider

Un projet bien maintenu est un projet sur lequel il est encore possible de faire des choix. Pas des choix théoriques, mais des décisions concrètes, prises sans urgence et sans crainte disproportionnée.

Quand la maintenance est absente ou subie, cette capacité s'érode progressivement. Chaque évolution devient risquée. Chaque correction soulève des interrogations. Le projet continue d'exister, mais il cesse d'être pilotable. Les décisions ne disparaissent pas, elles sont simplement reportées ou prises dans la contrainte.

À l'inverse, une maintenance pensée comme une stratégie redonne de la marge de manœuvre. Elle permet de décider quand faire évoluer, quand stabiliser, et quand ne pas agir. Elle rend les arbitrages possibles, parce que les conséquences sont mieux maîtrisées.

Cette capacité à décider est essentielle. Elle protège le projet des réactions impulsives, des refontes précipitées, et des changements dictés par l'urgence plutôt que par le besoin réel. La valeur de la maintenance ne se mesure pas en interventions, mais en liberté de décision.

Maintenir, ce n'est pas chercher à tout prévoir. C'est accepter que les projets évoluent, tout en se donnant les moyens de choisir leur trajectoire, plutôt que de la subir.

Conclusion

La maintenance n'est pas un problème technique mal compris. C'est un débat stratégique trop souvent déplacé.

Quand un projet numérique s'enlise, la technique encaisse. Elle devient l'obstacle commode, le responsable désigné, alors que la question réelle est ailleurs. Dans la capacité à piloter. À arbitrer. À décider sans urgence.

Maintenir un projet, ce n'est pas le figer. Ce n'est pas le complexifier. C'est refuser que la technique prenne toute la place, faute de cadre et de choix assumés. C'est créer les conditions pour que le débat porte sur le produit, les usages et le métier, pas sur ce qui aurait dû être anticipé. La maintenance n'est pas un coût. C'est ce qui empêche la technique de devenir un alibi.

Et tant qu'elle est pensée comme une stratégie, elle permet au projet de rester à sa juste place : un outil au service de décisions conscientes, plutôt qu'un frein que l'on subit quand il est déjà trop tard.

Photo de Caleb Jones sur Unsplash

Ma domotique n'est pas “smart” : elle est fiable (et c'est volontaire)

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

La domotique dite « smart » promet beaucoup. Dans la réalité d'un foyer, j'ai surtout cherché autre chose : un système fiable, discret et durable. Dans cet article, je partage un retour d'expérience assumé sur une domotique volontairement sobre, pensée non pour impressionner, mais pour s'effacer derrière les usages du quotidien.

Introduction

La domotique dite “smart” fait beaucoup de promesses. Elle parle d'intelligence, d'anticipation, d'automatisation poussée. Elle donne l'impression qu'une maison pourrait presque penser à notre place.

Très vite, j'ai compris que ce n'était pas ce que je cherchais.

Je ne voulais pas d'une maison spectaculaire, ni d'un système que je passe mon temps à surveiller. Je voulais quelque chose de plus simple, et paradoxalement plus exigeant : une domotique qui fonctionne. Tous les jours. Sans y penser. Sans dépendre d'un service extérieur. Sans avoir à vérifier, chaque matin, que tout est encore en ligne.

Avec le temps, une conviction s'est installée. Ce que l'on appelle “smart” décrit souvent une intention marketing plus qu'un usage réel. Dans la vie quotidienne, l'intelligence n'est pas dans la complexité, mais dans la fiabilité. Dans la capacité d'un système à se faire oublier, même quand tout ne se passe pas comme prévu.

Ma domotique n'est donc pas “smart”. Elle ne cherche pas à anticiper chaque geste, ni à multiplier les scénarios. Elle est volontairement sobre. Robuste. Prévisible. Elle accepte les exceptions, les imprévus, les vies qui débordent. Et surtout, elle continue de fonctionner quand je ne m'en occupe pas.

Cet article n'est pas un tutoriel, ni une liste de composants. C'est un retour d'expérience. Le récit d'un choix assumé : préférer une domotique fiable à une domotique brillante. Et considérer que, dans une maison habitée, c'est peut-être la forme la plus aboutie d'intelligence.

Ce que le mot « smart » cache vraiment

Le mot “smart” est séduisant. Il promet une maison intelligente, capable d'anticiper, d'optimiser, de décider. Dans les faits, il recouvre souvent autre chose : une dépendance accrue à des services extérieurs, à des mises à jour imposées, à des choix faits ailleurs.

Une domotique dite “smart” est fréquemment intelligente pour celui qui la vend, moins pour celui qui l'utilise au quotidien. Elle brille dans les démonstrations, beaucoup moins dans la durée. Quand tout va bien, elle impressionne. Quand quelque chose déraille, elle complique.

Très vite, je me suis rendu compte que cette intelligence affichée avait un coût caché. Comptes obligatoires, services distants, interruptions silencieuses, comportements qui changent sans que rien n'ait été demandé. La maison continue de fonctionner, mais plus tout à fait comme on l'avait décidé.

Ce que je cherchais n'était pas une maison qui anticipe à ma place. C'était une maison qui respecte mes choix, mes habitudes et mes imprévus. Une maison prévisible, compréhensible, maîtrisable.

À mes yeux, une domotique réellement intelligente est d'abord une domotique qui n'impose rien. Même si, à en croire mes enfants, celle que j'ai mise en place serait parfois un peu trop directive.

La fiabilité comme priorité absolue

Une maison n'est pas un terrain d'expérimentation. C'est un lieu de vie, avec des habitudes, des contraintes, des imprévus. Quand une automatisation ne fonctionne pas, ce n'est jamais anodin. Cela se voit, cela se ressent, et cela agace très vite.

Très tôt, j'ai fait un choix simple : privilégier ce qui tient dans le temps plutôt que ce qui impressionne. Une automatisation fiable est une automatisation prévisible. Elle fait ce qu'on lui demande, quand on le lui demande, sans surprise inutile. Et surtout, elle continue de fonctionner même quand je n'y pense pas.

Dans cette logique, une bonne automatisation est celle qu'on oublie. Elle n'attire pas l'attention. Elle ne demande pas d'arbitrage permanent. Elle s'efface derrière l'usage, au lieu de s'imposer à lui. La fiabilité n'est pas une option. C'est la condition pour que la domotique disparaisse du quotidien.

C'est cette exigence, parfois frustrante, qui m'a conduit à renoncer à certaines idées pourtant séduisantes. Non par refus de la technologie, mais par respect pour la vie réelle qui se déroule autour.

Pourquoi j'ai volontairement refusé certaines intégrations

Certaines intégrations sont séduisantes. Elles promettent une mise en place rapide, des fonctionnalités avancées, parfois même une impression de modernité immédiate.

Mais derrière cette simplicité apparente, il y a souvent une dépendance. À un service distant. À une API qui évolue sans prévenir. À un compte qu'il faut maintenir, surveiller, renouveler. La maison continue de fonctionner, jusqu'au jour où quelque chose change, ailleurs.

Avec le temps, j'ai compris que chaque intégration supplémentaire ajoutait une fragilité potentielle. Pas forcément visible, pas forcément immédiate mais réelle. Et dans un système censé faciliter le quotidien, cette fragilité finit toujours par se rappeler à vous.

Refuser certaines intégrations n'a donc jamais été un rejet de la technologie. C'était un choix de cohérence. Préférer moins de possibilités, mais plus de maîtrise. Accepter de renoncer à des fonctionnalités séduisantes pour préserver un équilibre plus robuste. Une domotique fiable est souvent une domotique qui sait dire non.

J'aurais aimé aller plus loin. Introduire une forme d'intelligence artificielle dans cette domotique. Explorer des usages plus adaptatifs, plus contextuels. L'idée est séduisante. Mais aujourd'hui, ces solutions impliquent presque toujours un abonnement, un service distant, et une opacité sur le devenir des données personnelles. Où elles vont. Comment elles sont traitées. Par qui. Dans une maison habitée, cette zone d'ombre est, pour moi, rédhibitoire.

Tant que l'intelligence artificielle impose de déléguer une partie de l'intimité du foyer à des services que je ne maîtrise pas, je préfère m'en passer. Ce n'est pas un refus de principe. C'est un report assumé.

J'introduirai de l'IA dans ma domotique le jour où je pourrai la faire fonctionner correctement, en local, sur un matériel que je contrôle.

Vivre avec une domotique, pas contre elle

Une domotique ne vit pas seule. Elle s'insère dans un quotidien déjà rempli d'habitudes, de contraintes et d'imprévus. Elle doit composer avec des horaires qui changent, des enfants qui grandissent, des routines qui évoluent.

Très vite, j'ai compris qu'un système trop rigide finit par se retourner contre ceux qui l'utilisent. Ce qui devait simplifier devient une source de friction. Une automatisation qui ne tolère pas l'exception devient un problème, pas une aide.

Dans la vie réelle, il y a toujours des écarts. Des lumières que l'on allume alors qu'elles devraient être éteintes. Des portes que l'on ouvre plus tôt que prévu. Des habitudes qui ne correspondent plus aux scénarios initiaux.

Une domotique viable est une domotique qui accepte ces écarts sans se dérégler. Elle ne cherche pas à corriger le comportement humain. Elle s'y adapte, discrètement. Une domotique qui ne tolère pas l'imprévu est une domotique fragile.

Mes règles personnelles, simples mais non négociables

Avec le temps, j'ai cessé de chercher la domotique idéale. J'ai préféré poser quelques règles claires, faciles à expliquer, faciles à maintenir. Elles ne couvrent pas tous les cas. Elles évitent surtout les mauvaises surprises.
La première est évidente, mais souvent oubliée : toujours un contrôle manuel. Chaque automatisation doit pouvoir être contournée sans effort. Un interrupteur, un bouton, une action simple. Rien n'est plus frustrant qu'un système qui impose son comportement.

La seconde est une conséquence directe : aucune automatisation sans possibilité de reprise. Un scénario qui ne peut pas être interrompu est un scénario dangereux. Pas au sens technique, mais au sens de l'usage quotidien.

Vient ensuite la sobriété. Peu de scénarios, mais compréhensibles. Peu de conditions, mais explicites. J'ai appris à renoncer à certaines automatisations simplement parce qu'elles ajoutaient plus de complexité que de confort.
Enfin, la maîtrise. Je privilégie ce qui fonctionne en local, ce que je peux observer, comprendre et maintenir. Pas par rejet du reste, mais par souci de cohérence. Ces règles ne rendent pas ma domotique spectaculaire. Elles la rendent habitable.

Ce que j'ai arrêté de faire

Avec le temps, j'ai arrêté d'automatiser par principe. Tout ce qui est automatisable n'a pas vocation à l'être. Certaines actions gagnent à rester manuelles, ne serait-ce que pour préserver une forme de liberté. À l'inverse, j'ai conservé des automatisations simples, presque évidentes. Les lumières s'éteignent la nuit, au cas où quelqu'un aurait oublié. Elles s'éteignent aussi automatiquement lorsqu'il n'y a plus personne à la maison. Rien de spectaculaire, juste du bon sens.

À l'arrivée, en revanche, la maison sait se montrer accueillante. Quand une personne entre et que la luminosité est insuffisante, la lumière de l'entrée s'allume. Pas besoin d'y penser. Pas besoin de chercher un interrupteur dans le noir.

Ces règles ne cherchent pas à optimiser chaque geste. Elles corrigent l'oubli, pas le comportement. Elles interviennent quand c'est utile, et s'effacent le reste du temps. J'ai aussi cessé de chercher la perfection. Une domotique parfaitement optimisée sur le papier devient vite fragile dans la réalité. J'ai appris à accepter des usages imparfaits, mais stables. Et surtout, compréhensibles par tous. Renoncer à certaines idées m'a permis de construire quelque chose de plus solide.

Conclusion

Ma domotique ne cherche pas à être impressionnante. Elle ne promet rien d'extraordinaire. Elle fait simplement ce pour quoi je l'ai conçue : accompagner le quotidien sans s'y imposer. Elle n'anticipe pas tout. Elle ne décide pas à ma place. Elle corrige les oublis, s'adapte aux imprévus, et disparaît quand elle n'est pas nécessaire. C'est ce compromis, volontairement sobre, qui lui permet de durer.

Je n'ai pas cherché à rendre ma maison intelligente. J'ai cherché à la rendre fiable.

Et dans un foyer habité, avec des vies qui évoluent et des habitudes qui changent, c'est sans doute la forme d'intelligence la plus utile que j'ai trouvée.

Photo de Spacejoy sur Unsplash

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

À propos de moi : un parcours construit par l'expérience

Teddy Payet — 2025-07-11T13:30:00Z

Du graphisme à la direction de projets numériques, mon parcours s'est construit pas à pas, à la croisée de la création, du code et de la stratégie. Chaque étape m'a apporté une compétence, une posture, une vision. Voici comment j'ai façonné, au fil des années, une approche du numérique profondément humaine, structurée et engagée.

Une trajectoire professionnelle entre créativité, technique et stratégie

Depuis plus de 25 ans, je trace un parcours professionnel à la croisière de trois dimensions : la créativité visuelle, la rigueur technique et la vision stratégique. Ce parcours, je ne l'ai pas planifié dans les moindres détails, mais il répond à une cohérence forte : comprendre, construire, transmettre. Il est aussi le reflet d'une volonté d'élargir sans cesse mon champ de compétences et d'enrichir ma posture professionnelle au fil des rencontres et des contextes.

Étape 1 : le graphisme comme point de départ

Formé aux arts appliqués (Bac STI + BTS), puis à l'école multimédia, j'ai commencé ma carrière dans le graphisme print et web. Travailler sur l'image, la mise en page, la typographie m'a appris à être exigeant sur la forme, à valoriser le sens à travers la lisibilité, la hiérarchie visuelle, la compréhension immédiate. J'ai appris à travailler vite, avec rigueur, dans le respect des délais et des contraintes imposées par le print comme le digital.

Ce contact direct avec le visuel m'a ancré dans une logique de communication claire et efficace, essentielle pour capter l'attention dans des environnements saturés d'informations.

Ce que j'en retiens : une attention permanente au détail, au message, à la cohérence entre fond et forme. Une qualité que je mets aujourd'hui au service de l'UX, de la stratégie de contenu, et des projets dématérialisés complexes. J'ai gardé de cette période le goût du beau utile.

Étape 2 : le code comme langage d'action

Rapidement, j'ai basculé du côté du développement web. J'ai approfondi mes compétences en HTML/CSS, puis en PHP, JS, MySQL, en travaillant pour des ESN comme Acensi ou Netapsys. De développeur frontend, je suis devenu fullstack, puis lead dev. Ce passage a transformé ma manière de penser : du pixel, je suis passé à la logique, au modulaire, à la structuration des données et des fonctionnalités.

Je me suis approprié des outils, des frameworks, des patterns. J'ai travaillé sur des projets exigeants, en équipe, dans des environnements mouvants, avec un souci permanent de qualité et de performance.

Ce que j'en retiens : une capacité à structurer, décomposer, automatiser, anticiper. Le code m'a apporté une logique d'efficacité, une rigueur, mais aussi une agilité. J'ai appris à dialoguer avec les machines, mais surtout à dialoguer avec les équipes techniques et fonctionnelles. J'ai compris que derrière chaque fonctionnalité se cache un besoin humain à traduire et à simplifier.

Étape 3 : la gestion de projet comme levier d'impact

Avec l'expérience, j'ai naturellement pris des responsabilités de pilotage. Chef de projet, scrum master, manager d'équipe, j'ai accompagné la mise en place de workflows, de méthodes agiles, de CI/CD, de produits structurés. J'ai piloté des projets complexes, coordonné des profils variés, pris des décisions parfois difficiles.

Cette période m'a permis de me confronter à la réalité du terrain : arbitrages, imprévus, écoute des besoins, posture d'interface entre plusieurs mondes (technique, métier, direction).

Ce que j'en retiens : la nécessité de concilier vision et opérationnel. J'ai appris à gérer les risques, les calendriers, les parties prenantes, tout en gardant le sens du projet. La gestion de projet m'a aussi permis de développer mon sens de la communication, de la pédagogie, du pilotage par la valeur. J'ai compris que le livrable le plus précieux, c'est souvent la relation qu'on construit.

Étape 4 : la stratégie numérique comme posture de direction

Mon rôle de CTO chez Star Invest et mes années de freelance m'ont permis d'acquérir une vision systémique des projets : du cadrage à la livraison, de l'accompagnement du changement à la structuration technique, du choix d'architecture à la gouvernance. J'ai appris à anticiper, prioriser, accompagner les décisions stratégiques.

Freelance, j'ai aussi appris à gérer une relation client de A à Z : écoute, conseil, proposition de valeur, production, suivi, bilan. J'y ai affermi mon autonomie et ma vision d'ensemble.

Ce que j'en retiens : le goût de la vision long terme, le sens de la responsabilité, la capacité à accompagner les décideurs. J'y ai développé une posture de conseil, d'appui, de facilitateur. Cela m'a appris à prendre de la hauteur sans perdre le contact avec la réalité opérationnelle.

Étape 5 : aujourd'hui, au service de l'intérêt général

Depuis 2024, j'occupe le poste de chef de pôle Web & Produits Numériques au sein du CGDD. Une mission publique, où je mets à profit l'ensemble de mes compétences passées au service de projets d'information, de communication et de transition écologique.

J'y accompagne la conception et l'évolution de sites ministériels, la transformation de notre offre de service, la structuration de nos outils internes, le pilotage de la qualité, de l'accessibilité et de l'innovation. Je veille aussi à la cohérence entre nos outils, nos messages et les attentes des usagers.

Ce que j'y engage : mon expérience, mais aussi ma conviction. Travailler pour le service public, c'est aussi mettre en cohérence son savoir-faire avec ses valeurs. C'est accepter de construire dans le temps long, avec rigueur, transparence, et une exigence de clarté et d'impact.

Concevoir des solutions concrètes et évolutives

Ce que j'aime par-dessus tout dans mon métier, c'est penser, créer et développer des solutions qui simplifient le quotidien de mes interlocuteurs. Et je ne les conçois jamais seul. À chaque étape, mes interlocuteurs prennent pleinement part aux échanges : l'outil naît d'une réflexion coconstruite, nourrie par les besoins, les usages, les contraintes de terrain. Concevoir un outil utile, en observer la prise en main, puis le voir évoluer avec les retours du terrain : c'est là que je trouve du sens.

J'aime que les idées deviennent actions, que le besoin initial prenne forme dans un produit tangible, modulable, réellement utilisé. Être dans le concret, dans l'usage, dans l'amélioration continue : cela guide chacune de mes décisions. Je ne cherche pas à livrer un livrable figé, mais à co-construire un outil vivant, au service de celles et ceux qui s'en serviront demain.

En bref

Chaque étape de mon parcours m'a appris à penser plus large, à faire plus juste, à transmettre plus simplement.

Je ne suis pas qu'un technicien, pas qu'un stratège, pas qu'un manager. Je suis un professionnel qui relie les gens, les idées et les outils. Et aujourd'hui, je le fais au service du collectif, de la lisibilité de l'information publique, et de la transition numérique de l'État.

Photo de Fili Santillán sur Unsplash

Ma personnalité au service du sens

Teddy Payet — 2025-07-11T09:30:00Z

Pourquoi écrire sur sa personnalité dans un cadre professionnel ?

Sur un blog personnel orienté vers mon activité professionnelle, il pourrait sembler inhabituel de parler de moi, non pas en tant que chef de projet ou développeur, mais en tant qu'homme. Et pourtant.

Je suis convaincu que nos projets, nos façons de diriger, de créer ou de collaborer sont profondément liés à qui nous sommes. Travailler avec quelqu'un, c'est aussi adhérer à sa manière d'écouter, de décider, de résoudre, de tisser des liens.

Voici donc un portrait plus personnel, pas pour me raconter, mais pour mettre en lumière ce qui m'anime et ce que j'apporte dans chaque mission : une posture, une énergie, une vision.

Entre vision claire et ancrage solide

Je suis habité par une dynamique constante : voir loin tout en gardant les pieds sur terre.

Je navigue naturellement entre la stratégie et la concrétisation. J'aime bâtir des architectures, prévoir les enjeux à long terme, structurer une feuille de route, tout en prenant soin de la mise en œuvre concrète. Ce double mouvement me rend à la fois visionnaire et artisan.

Ma capacité à anticiper, relier, structurer me permet de créer des environnements où l'efficacité n'est jamais coupée du sens. J'accorde autant d'attention à la direction que l'on prend qu'aux moyens que l'on met en œuvre pour y parvenir. Il ne s'agit pas simplement de viser un objectif : il s'agit d'y aller de manière alignée, respectueuse, durable.

J'aime concevoir des systèmes pérennes, évolutifs, documentés, et je prends autant de plaisir à imaginer une vision ambitieuse qu'à orchestrer les étapes précises qui la rendront possible. La cohérence globale me passionne : entre les briques techniques, les attentes métiers, les réalités de terrain, et les dynamiques humaines. C'est ce tissage que je cherche à faire apparaître dans mes projets.

Ce qui m'anime, c'est de rendre les choses lisibles, structurées, compréhensibles pour chacun, tout en gardant une vue d'ensemble stratégique. Car une vision n'a de valeur que si elle est partagée, portée, traduite dans le réel.

La quête de justesse

Ce qui me guide au quotidien, c'est la recherche de l'alignement : entre les valeurs affichées et les décisions prises, entre les intentions et les actes, entre la promesse et l'expérience vécue.

Cela se traduit dans ma manière de travailler :

Un goût pour la clarté, dans les projets comme dans les relations.
Une attention portée aux détails sans perdre de vue l'ensemble.
Un engagement dans la cohérence, même quand elle demande du courage.

C'est aussi cela, pour moi, être professionnel : ne jamais faire semblant.

Structuré, mais sensible

Je suis un homme à la fois rigoureux et à l'écoute. Cette alliance, je ne l'ai pas construite en théorie : je l'ai forgée sur le terrain, dans les équipes, dans les projets, dans les moments de tension comme dans les réussites partagées. Je valorise les processus bien construits, les cadres robustes, les stratégies lisibles. J'aime quand les choses sont organisées, lisibles, documentées. Je crois au pouvoir du cadre pour apaiser, pour clarifier, pour faire gagner du temps et de l'énergie à tous.

Mais j'y intègre toujours une place pour l'imprévu, pour l'humain, pour le ressenti. Un projet n'est pas qu'un enchaînement de jalons ou un diagramme de Gantt. C'est une aventure humaine, faite d'engagements, de doutes parfois, de prises de décision collectives, de compromis assumés. Dans ces moments-là, ma sensibilité est une force. Elle me permet de capter les signaux faibles, de détecter quand une personne décroche, quand un échange devient stérile, quand une tension non dite mine une dynamique.

Être sensible, ce n'est pas être fragile. C'est être attentif. Présent. Connecté. Cela me permet de réguler, d'apaiser, d'intervenir sans imposer. J'aime créer les conditions d'un climat de confiance, dans lequel chacun peut trouver sa place, exprimer ses idées, ses freins, ses élans.

Je crois que l'on peut être exigeant sans être rigide. Fort sans être fermé. Et que le rôle d'un responsable n'est pas de briller seul, mais de faire en sorte que l'équipe avance, progresse, se sente valorisée.

Je m'efforce de faire vivre cela dans mes projets comme dans mes relations de travail. Chaque jour.

Rugby : une école de vie, un terrain de valeurs

Depuis plusieurs années, je joue au rugby loisir avec Les Pierrozes, à Triel-sur-Seine.
Je ne suis pas encyclopédique sur le palmarès des grandes équipes, mais j'aime profondément l'esprit du rugby au quotidien :

la solidarité,
le collectif,
la résilience,
la fraternité.

Sur le terrain comme dans les projets, j'avance avec cette même philosophie :

On gagne ensemble, on apprend ensemble, on se relève ensemble.

Le coquinou : une anecdote révélatrice

Dans mon équipe, un petit rituel est né : mon planteur maison, surnommé le coquinou, est devenu une boisson emblématique. Ce n'est pas qu'un cocktail. C'est une manière de partager mes racines réunionnaises, de prolonger l'énergie du terrain autour d'un moment vrai.

Lors d'un événement privé avec des amis du rugby, une invitée confiait ne pas aimer le rhum. Par curiosité, et un peu par politesse, elle a tout de même goûté au coquinou. Résultat ? Séduite, elle en a bu tout au long de la soirée (avec modération, bien sûr).
Cette scène m'a marqué. Elle illustre parfaitement ce que je crois : quand on reste fidèle à ce qu'on est, quand on agit avec sincérité et générosité, on touche les autres. On ouvre des chemins inattendus.

Ce que cela change dans ma manière d'accompagner un projet

Cette posture, je l'incarne aussi dans mon métier. J'ai commencé à accompagner une cliente il y a plus de 15 ans, la responsable du réseau RAMAU. Je lui ai apporté mon expertise, mais aussi une capacité d'écoute, de transmission, de projection.
Aujourd'hui encore, elle sait qu'elle peut me solliciter pour un conseil, une solution, une vision.
Et je suis là. Parce que je crois dans la continuité, la confiance, l'engagement sur le long terme.

Mon blason personnel

Pour symboliser cette personnalité multiple, j'ai conçu un blason personnel, à la manière d'un archétype graphique.

Blason

Il condense quatre de mes piliers :

L'arbre : la force tranquille et les racines
L'œil : la vision stratégique et l'intuition
Le marteau : la construction concrète et rigoureuse
Le calice : la sensibilité, l'écoute, l'authenticité

Et cette devise :

Construire avec le cœur, veiller avec l'âme.

Ma manière de travailler, en 5 mots

Clarté
Engagement
Écoute
Créativité
Transmission

Et vous ?

Aujourd'hui, je ne mène plus d'activité en freelance. Depuis ma prise de poste comme chef de pôle au sein du CGDD, je mets pleinement mon expérience, mon énergie et mon expertise au service des projets numériques du ministère, de mon équipe et de nos publics.

Mais je reste ouvert aux échanges, aux discussions inspirantes, aux retours d'expérience. Si ce portrait vous parle, si vous partagez des valeurs similaires, ou si vous avez simplement envie d'échanger autour d'un projet, d'une vision ou d'un bon café… je serai ravi de discuter.

Photo de Johann Siemens sur Unsplash

Magic Mirror avec Home Assistant, pour aller plus loin…

Teddy Payet — 2025-06-14T06:30:00Z

Cette série d'articles vous a permis de suivre étape par étape la création de mon Magic Mirror domotique, piloté par Home Assistant : un tableau de bord mural affichant l'heure, la météo, les calendriers, la présence des membres de la famille, les températures de la maison, ou encore la phase lunaire.

Mais le projet ne s'arrête pas là. Le véritable pouvoir de Home Assistant réside dans sa capacité à s'adapter. Voici donc quelques idées concrètes pour améliorer, étendre ou personnaliser encore plus votre Magic Mirror.

🕰️ 1. Affichage contextuel selon l'heure de la journée

Au lieu d'une simple rotation fixe entre les pages, vous pouvez afficher des vues différentes en fonction du moment de la journée :

Le matin (6h–10h) : calendriers et météo
L'après-midi : températures et phase lunaire
Le soir : rappel de la routine / compliments

Cela se fait via une automatisation Home Assistant combinant browser_mod.navigate et une condition horaire :

condition: "{{ now().hour < 10 }}"

🧍‍♂️ 2. Affichage basé sur la présence

Pourquoi ne pas adapter l'affichage selon qui est à la maison ?

Exemples :

Si seul l'un des enfants est présent, afficher uniquement son agenda.
Si la maison est vide, afficher une animation ou un écran de veille.
Si un invité est détecté (mode invité), désactiver la rotation.

Tout cela est possible via les entités person.*, ou les capteurs de présence (Bluetooth, Wi-Fi, etc.).

💬 3. Affichage de messages personnalisés

L'entité input_text.compliments utilisée pour les compliments peut être détournée pour afficher :

des messages contextuels ("Bonne journée Salomé !", "Rendez-vous médical à 14h"),
des alertes météo ou pollution,
des rappels d'organisation familiale.

Automatisations possibles :

- alias: Message anniversaire trigger: - platform: time at: "07:30:00" condition: - condition: template value_template: "{{ now().date() == states('sensor.birthday_today') }}" action: - service: input_text.set_value data: entity_id: input_text.compliments value: "Joyeux anniversaire, Johan ! 🎉"

🌐 4. Flux d'actualités ou d'informations publiques

Si vous souhaitez enrichir votre affichage avec des contenus extérieurs :

Flux RSS d'actualité locale ou nationale (via rss_feed)
Affichage du trafic routier (via Waze ou Google Maps)
Infos sur les jours de grève ou alertes publiques

Ces contenus peuvent être affichés sous forme de markdown, custom:text-element, ou même via une iframe dédiée.

J'avoue que je n'ai pas trouvé un affichage qui me plaise esthétiquement pour le RSS feed. Les solutions que je trouvais étaient pour l'affichage d'un tableau alors que je veux un surtitre (le nom de la source et la date relative de la news), le titre de l'article de news. Un à la fois, pas tout en bloc. Épuré…

🌡️ 5. Capteurs personnalisés via MQTT

Si vous êtes équipé de capteurs maison (ESPHome, Tasmota…), vous pouvez :

Ajouter des données météo ultra-locales
Suivre l'humidité du salon
Afficher la qualité de l'air intérieur

Home Assistant est pleinement compatible avec MQTT, ce qui permet d'exploiter toutes vos données dans le Magic Mirror.

🔐 6. Mode veille et sécurité

Un écran allumé en permanence peut être une gêne ou une perte d'énergie. Voici quelques idées :

Éteindre l'écran la nuit ou en absence prolongée (xrandr, vcgencmd, ou via une prise connectée)
Verrouiller l'accès à certaines pages
Ajouter un mode veille doux (horloge simple, fond noir)

🧪 Et au-delà…

Le Magic Mirror peut aussi servir de :

Tableau d'affichage dans une entrée d'immeuble
Tableau de bord d'atelier ou d'entreprise
Écran d'accueil pour une salle d'attente
Support pédagogique dans une école

La seule limite ? L'imagination. Et la RAM du Raspberry Pi 😄

Merci pour votre lecture !

Cette série est née d'un simple partage d'écran sur un groupe Home Assistant, et vous êtes quelques uns à avoir manifesté votre curiosité. J'espère qu'elle vous aura inspiré à créer, personnaliser et faire vivre vos propres interfaces. Je me suis aidé aussi d'une IA générative pour créer rapidement cette série d'articles. J'ai modifié des éléments pour rester conformes à mon idée et mon écriture.

Si vous avez des questions ou souhaitez partager vos créations, n'hésitez pas à me contacter via mon site.

À très bientôt, et bonne domotique à vous 🚀

Magic Mirror avec Home Assistant

Pourquoi j'ai intégré Home Assistant dans mon MagicMirror (9 juin)
Installer et configurer HACS pour enrichir Home Assistant (9 juin)
Construire les pages Lovelace du Magic Mirror (9 juin)
Calendriers, routines et organisation familiale (Page 2) (10 juin)
Suivi de l'environnement et bien-être (Page 3) (11 juin)
Automatiser la rotation des pages du Magic Mirror (12 juin)
Personnalisation et astuces d'affichage avec card_mod (13 juin)
Magic Mirror avec Home Assistant, pour aller plus loin… (14 juin)