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

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.