Teddy Payet

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

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

Association Didattica

Teddy Payet — 2012-05-18T13:00:00Z

Présentation de l'association
L'association didattica est un collectif qui travaille à la croisée de l'architecture, de l'éducation et de la démocratie, avec comme mot d'ordre "pour une prise de position de tous et de chacun dans le monde physique, social et mental". Elle rassemble des architectes, des artistes, des chercheurs, des enseignants (du primaire, secondaire et supérieur) et des étudiants de différentes disciplines. Tâches réalisées
– Intégration du nouveau graphisme du site (…)

- Développement / SPIP, Traitement automatique des images, CSS, Web Design, MySQL, Associaiton Didattica, Chef de projet, Développeur Web, Intégrateur, Freelance, Sublime Text, NetBeans

AMP

Teddy Payet — 2012-05-07T09:00:37Z

Site du laboratoire de recherche "Architectures, Milieux, Paysages" de l'École Nationale Supérieure d'Architecture de Paris la Villette.
Voici le 2ème site réalisé dans la refonte des sites des laboratoires de l'ENSAPLV. Le squelette a été enrichi par rapport à la première version (cf. MAP-MAAC) pour répondre à différents critères de classification AERES.
– Utilisation intensive du plugin Compositions 2.0 basé sur le squelette Zpip ;
– Création d'un petit javascript maison pour (…)

- Développement / SPIP, Photoshop, XHTML, CSS, Web Design, MySQL, École Nationale Supérieure d'Architecture de Paris Lavillette (ENSAPLV), PHP, Javascript, Chef de projet, Développeur Web, Freelance, Sublime Text, SVN

MAP-MAACC

Teddy Payet — 2012-03-20T14:59:00Z

MAP-MAACC (Modélisations pour l'Assistance à l'Activité Cognitive de la Conception) est un laboratoire de recherches de l'École Nationale Supérieure d'Architecture de Paris Lavillette (ENSAPLV). Le site a été porté sous SPIP 2.1.12 pour permettre une recherche transversale des différents laboratoires de l'école. La mise en page du site sert de gabarit pour tous les autres laboratoires. Les couleurs changeront selon le laboratoire mais les fonctions restent les même.

- Développement / SPIP, Traitement automatique des images, CSS, Web Design, MySQL, École Nationale Supérieure d'Architecture de Paris Lavillette (ENSAPLV), Javascript, Chef de projet, Développeur Web, Intégrateur, Freelance, jQuery, Sublime Text, NetBeans, SVN

Temple de Paris, v3

Teddy Payet — 2007-09-25T07:27:00Z

Réalisation de la 3é version du site de l'église évangélique "Temple de Paris" avec une approche "magazine".

- Développement / SPIP, Photoshop, Traitement automatique des images, XHTML, CSS, Dreamweaver, Web Design, MySQL, Temple de Paris, Chef de projet, Développeur Web, Intégrateur, Graphiste, Bénévole