Pourquoi cet article maintenant

Tiki suit un cycle de vie cadencé : une version majeure tous les huit mois, et une LTS toutes les trois versions, supportée cinq ans. Ce support se découpe en deux temps : une période de support complet (corrections de bugs et petites améliorations), suivie d'une période plus longue de corrections de sécurité uniquement. Tiki 27 entre précisément dans cette seconde phase à mesure que Tiki 30 se stabilise, d'où l'urgence de bouger. Cette version restera sous surveillance sécurité jusqu'en 2029, mais sa fenêtre de support fonctionnel se referme : plus de corrections de bugs ni d'améliorations au-delà de mi-2026. Tiki 28 et 29 sont des versions à support court (STS) qui ont servi de laboratoire à la modernisation. Et Tiki 30 LTS, attendue pour l'été 2026, deviendra la prochaine destination de référence pour la production… une fois passées les premières versions de maintenance qui confirment sa stabilité.

La question n'est donc pas de savoir si vous devez migrer, mais quand et par quel chemin. C'est tout l'objet de cet article : faire une synthèse de ce qui a changé, fonctionnalité par fonctionnalité, de Tiki 27 à Tiki 30, puis exposer la stratégie de migration que nous vous recommandons.

La stratégie en une phrase

Ne restez pas sur Tiki 27 en attendant Tiki 30 : faites une transition plus souple en passant d'abord par Tiki 29.
Tiki 27 perd son support fonctionnel mi-2026, et Tiki 30 n'est pas encore mûr pour la production. Tiki 29 est la version stable la plus récente : elle prépare techniquement le terrain (les mêmes briques modernisées dont Tiki 30 hérite), et elle vous fait tenir confortablement jusqu'à ce que Tiki 30 LTS soit prête. Surtout, elle vous laisse le temps de corriger vos thèmes, d'affiner vos paramètres, de renforcer la sécurité, d'informer et de former vos équipes : de rejouer la pièce avant la représentation générale. C'est le chemin progressif et sans à-coups que nous empruntons pour nos clients, et qui revient au final à gagner du temps et de l'argent.

Vue d'ensemble : la trajectoire 27 → 30

Tiki 27 a été une LTS exceptionnelle : les développeurs y ont concentré des changements habituellement réservés aux versions intermédiaires, Smarty 4 → 5, nouveau système de build basé sur npm, PHPUnit 10, et surtout le passage à PHP 8.1/8.2/8.3 (étendu jusqu'à 8.4 dans les versions de maintenance), décrit par l'équipe comme la montée de version PHP les plus difficiles en plus de vingt ans d'existence du projet.

Tiki 28 et 29 sont des versions STS (Standard Term Support, support court) qui ont poursuivi la modernisation :

  • migration du moteur de base de données vers InnoDB pour l'index unifié ;
  • remplacement de bibliothèques vieillissantes ;
  • durcissement de la sécurité ;
  • nombreuses améliorations d'usage.

Tiki 30 va devenir la nouvelle LTS et, contrairement à Tiki 27, elle revient à la philosophie classique d'une LTS : surtout du raffinement, peu de ruptures. Les gros bouleversements suivants sont annoncés pour Tiki 31.

Les changements fonctionnalité par fonctionnalité

Pages wiki et outils d'édition

C'est l'un des domaines où les changements sont les plus concrets pour les utilisateurs au quotidien, et il faut bien distinguer les deux éditeurs en ligne que propose Tiki, l'éditeur Markdown / TOAST UI d'un côté, et l'éditeur WYSIWYG de l'autre.

Côté Markdown, le gros chantier a eu lieu dans Tiki 27, avec le passage à un éditeur de texte en mode Markdown (compatible Tiki ou pur jus) et à l'éditeur TOAST UI, rendant l'expérience plus agréable sans casser la compatibilité avec la syntaxe Tiki traditionnelle. Tiki 28 a poursuivi en corrigeant des défauts d'ergonomie et en améliorant la génération et la prévisualisation PDF.

Mais le changement le plus structurant arrive avec Tiki 29, qui remplace CKEditor 4 par Summernote comme éditeur WYSIWYG. La raison est autant technique que stratégique, CKEditor 4 n'étant plus open source. Summernote est un éditeur basé sur Bootstrap, thémable, doté d'une barre d'outils personnalisable et d'une intégration CodeMirror fonctionnelle. Le collage a aussi été amélioré. Le contenu mis en forme (gras, couleurs, styles) copié depuis un traitement de texte ou une page web conserve désormais sa mise en forme lors de la conversion en page Tiki, ce qui réduit le nettoyage manuel. C'est un point de vigilance majeur pour votre migration, car le moteur d'édition change sous le capot.

Côté accessibilité, la structure des pages a été revue pour la conformité WAI/508. Comme à chaque version, les développeurs y portent une attention particulière et cherchent à décrocher les meilleurs scores aux tests de validation du W3C, qu'il s'agisse de la structure du code ou du rendu visuel. C'est un point qui compte si votre site doit répondre à des obligations légales d'accessibilité, de plus en plus fréquentes dans le secteur public et les grandes organisations.

Fichiers (File Gallery)

Pour bien situer les nouveautés, rappelons que Tiki gère les fichiers à deux niveaux. Il y a les galeries de fichiers classiques, c'est-à-dire le gestionnaire de documents du site, avec versions, brouillons, accès WebDAV, vues en liste ou vignettes. Et il y a le champ « Fichiers » des trackers, qui permet d'attacher des documents directement à une fiche. C'est sur ce second point que les évolutions récentes sont les plus parlantes.

La nouveauté marquante vient de Tiki 29. Le champ de tracker de type « Fichiers » peut désormais créer automatiquement une galerie de fichiers dédiée par élément de tracker. Concrètement, chaque fiche (profil utilisateur, article, facture, contrat, signature) reçoit sa propre galerie, au lieu de voir tous les documents s'entasser dans un dépôt commun. Pour quiconque utilise les trackers comme une base de données métier (gestion de dossiers clients, de contrats, de demandes), c'est un vrai gain d'organisation. Les documents restent rattachés à leur contexte, et l'arborescence reste lisible même après des milliers d'items. L'interface de téléversement de ce champ a par ailleurs été significativement enrichie.

Tiki 29 a aussi tissé un lien direct entre la webmail et les fichiers. Lorsqu'on envoie un email depuis Cypht, Tiki peut suggérer l'élément de tracker pertinent et y classer l'email envoyé. La messagerie alimente ainsi automatiquement le dossier documentaire de la fiche concernée, ce qui sert la traçabilité du support client et des projets.
Tiki 30 prolonge cette logique côté entrée des données. Une nouvelle préférence (email_to_tracker_mode) permet de choisir si les emails sont déplacés ou copiés lorsqu'ils servent à créer des éléments de tracker depuis une boîte IMAP, un détail qui compte en environnement de test ou de pré-production, où l'on veut souvent conserver les messages d'origine.

Pour le reste, le gestionnaire de fichiers continue de reposer sur les briques connues. Interface standard ou interface elFinder (glisser-déposer depuis le poste de travail, actions contextuelles au clic droit), téléversement par lot, et stockage des images dans des galeries qui servent de fait de galeries d'images.

Trackers (la base de données intégrée et les formulaires)

Les trackers sont le cœur applicatif de Tiki : son constructeur de bases de données et son framework low-code / no-code, l'équivalent libre d'un Microsoft Access ou d'un FileMaker. Ils évoluent à chaque version, et la série 28 → 30 apporte à la fois des nouveautés fonctionnelles et un point de migration à ne pas négliger.

Tiki 28 a d'abord travaillé l'usage et la mobilité. La bibliothèque Sortable.js permet désormais le glisser-déposer des champs sur les appareils tactiles, ce qui rendait jusque-là la configuration d'un tracker pénible sur tablette ou smartphone. Surtout, les trackers hors ligne deviennent exploitables dans le cadre de la fonctionnalité PWA (Progressive Web App) : une fois la PWA activée et le paquet Dexie installé, un tracker sélectionné peut être renseigné sans connexion, les données étant synchronisées ensuite — utile pour la saisie terrain (inventaire, relevés, interventions). Cette fonctionnalité, longtemps expérimentale, a été reprise et fiabilisée entre Tiki 27 et 28.

Mais Tiki 28 embarque aussi le principal point de vigilance migration de toute cette série : la bascule des clés de champ de fieldID vers permName (nom permanent), via le mécanisme unified_trackerfield_keys. Concrètement, toute configuration qui s'appuyait sur l'identifiant numérique du champ (fieldID) est migrée vers le nom permanent. Pour la grande majorité des sites, les scripts de mise à jour gèrent la conversion automatiquement. Mais si vous avez du code personnalisé, des plugins sur mesure, des exports ou des intégrations qui référencent des champs par leur fieldID, ces références doivent être revues : c'est exactement le type de changement de fond qui justifie de migrer par étapes et de tester sur une pré-production plutôt que de basculer directement en production.

Tiki 29 est la version la plus riche côté fonctionnalités. Elle ajoute un nouveau type de champ code-barres / QR code, précieux dès qu'on touche à la logistique, à l'inventaire ou au suivi d'actifs. Elle introduit aussi l'enregistrement audio en ligne directement dans un élément de tracker, avec aperçu de la forme d'onde et lecture intégrée — pratique pour des notes vocales, des comptes rendus ou de la documentation de terrain. Côté fichiers, le champ « Fichiers » gagne la création automatique d'une galerie dédiée par item (voir la section Fichiers), et un pont intelligent relie la webmail Cypht aux trackers : à l'envoi d'un email, Tiki suggère l'élément de tracker pertinent et peut y classer le message, ce qui prépare aussi le routage automatique des réponses via un champ « dossier email » et des règles Sieve. Pour qui exploite les trackers comme outil de gestion (support client, dossiers, projets), c'est un vrai gain de traçabilité.

Tiki 30, en bonne LTS de raffinement, consolide plutôt qu'il ne bouleverse. Côté saisie par email, une nouvelle préférence (email_to_tracker_mode) permet de choisir si les messages sont déplacés ou copiés lors de la création d'éléments depuis une boîte IMAP — un confort en environnement de test où l'on veut conserver les originaux. L'interface d'administration des notifications de changements de tracker (tiki-admin_notifications.php) a par ailleurs été clarifiée pour retrouver plus facilement des réglages comme la copie de l'activité d'un tracker entier vers un email. Enfin, la nouvelle file de tâches en arrière-plan (commande queue:process) bénéficie indirectement aux trackers lourds, en déchargeant les opérations longues comme certaines générations de documents.

La performance et le retour d'erreur (feedback on error) ne sont pas en reste, avec une amélioration continue de version en version et l'ajout d'un paramètre qui permet aux plugins récupérant des éléments de tracker de ne lire que les champs ayant besoin d'être rapatriés, ce qui allège nettement les listes tirées de gros trackers.

En résumé : la valeur fonctionnelle est surtout dans Tiki 29 (nouveaux champs, audio, lien webmail), mais le travail d'administration à anticiper est dans Tiki 28 (migration fieldID → permName).

Système de recherche (Unified Index - MySQL, Elasticsearch and Manticore)

C'est l'un des domaines où le travail de fond est le plus important sur cette série de versions, et il vaut la peine de poser le décor. Depuis des années, Tiki repose sur un index unifié : un index central qui alimente la recherche du site, mais aussi PluginList, PluginCustomSearch et la plupart des fonctionnalités qui listent ou filtrent du contenu. Cet index peut s'appuyer sur plusieurs moteurs au choix — la recherche plein-texte native de MariaDB/MySQL (par défaut, intégrée, idéale jusqu'à des projets de taille moyenne), ou des moteurs externes plus puissants comme Manticore Search (rapide, économe en RAM) ou Elasticsearch/OpenSearch (pour les très gros volumes). En règle générale, on peut changer de moteur et reconstruire l'index sans toucher au reste de la configuration.

Tiki 28 apporte des changements structurants comme la bascule de l'index unifié de MyISAM FULLTEXT vers InnoDB FULLTEXT. Au-delà de la robustesse d'InnoDB, ce changement a une conséquence très concrète pour les utilisateurs intensifs de trackers : il fait sauter la limite historique du nombre de champs indexables.

Côté confort de recherche, Tiki 28 introduit deux nouveautés très visibles pour l'utilisateur final. D'abord le « Did You Mean ? », qui suggère une correction orthographique quand aucune correspondance exacte n'est trouvée. Ensuite la recherche floue (fuzzy search), qui tolère directement les fautes de frappe et les variations légères. Ces fonctions marchent pleinement avec le moteur Manticore, et Tiki 28 les a aussi rendues disponibles pour les recherches basées sur MySQL, donc accessibles même aux installations les plus simples.

Tiki 29 poursuit côté administration de l'index. La commande index:cleanup, introduite pour éviter le gonflement du système de fichiers d'indexation, devient plus sûre : elle détecte si un index est partagé entre plusieurs instances Tiki avant toute suppression, pour prévenir les pertes accidentelles. Une nouvelle préférence (unified_check_unused_indexes) permet de repérer les index inutilisés, et des options supplémentaires (--all, --dry-run, suppression ciblée) donnent un contrôle plus fin. La gestion d'Elasticsearch a aussi été refondue pour plus de fiabilité.

Point de vigilance migration. La recherche est précisément le genre de sous-système qu'il faut tester après une mise à niveau. Le passage à l'index InnoDB (Tiki 28) implique de reconstruire l'index unifié après migration, et c'est l'occasion de vérifier le moteur retenu et le temps de reconstruction (règle empirique : si la reconstruction prend moins de trente minutes, vous n'avez en principe rien à craindre). Rappel hérité de Tiki 27 : l'ancien moteur de recherche Tiki historique, déprécié depuis 2018, a été complètement supprimé. Si une configuration ancienne s'appuyait encore dessus, l'index unifié est désormais le seul chemin.

Calendrier

Le calendrier est l'un des domaines où Tiki a le plus investi sur cette série de versions, et il faut comprendre l'architecture pour mesurer la portée des changements. Depuis Tiki 21, le calendrier s'appuie sur un serveur CalDAV intégré (via SabreDAV), qui permet la synchronisation avec des applications externes (clients de bureau, mobiles, autres sites) et la gestion des invitations par email en lien avec la webmail Cypht.

Tiki 27 a porté la refonte la plus profonde. Les opérations sur les événements (création, modification, suppression) passent désormais systématiquement par le serveur CalDAV interne, ce qui garantit que la planification, la génération des messages d'invitation iTIP et les plugins associés réagissent correctement à chaque changement. Concrètement, cela débloque plusieurs fonctionnalités importantes : la prise en charge quasi complète des règles de récurrence de la norme RFC 5545 (au-delà du simple « tous les X jours/semaines/mois », on gère des cas comme « le dernier vendredi de chaque mois ») ; la définition de blocs de disponibilité par utilisateur, qui alimentent les rapports de disponibilité et le bouton « vérifier la disponibilité » ; les créneaux de rendez-vous (appointment slots), où un bloc de disponibilité se transforme en plage réservable — un visiteur, voire un utilisateur anonyme si la permission le permet, choisit un créneau et crée le rendez-vous, le tout intégrable dans un site externe via iframe ; et enfin les calendriers privés personnels, visibles seulement de leur créateur et des administrateurs de calendrier, avec une permission dédiée. C'est, en pratique, une brique de prise de rendez-vous comparable à des services spécialisés, intégrée nativement.

Tiki 28 a ajouté une touche d'usage attendue : la possibilité d'inscrire une note texte en répondant à une invitation, et de voir ces notes sur les confirmations entrantes — un comportement familier aux utilisateurs de services comme Roundcube.

Tiki 29 a opéré un changement technique sous le capot : la bibliothèque FullCalendar a été remplacée par Event-Calendar (@event-calendar), à la fois dans le calendrier principal et dans le plugin Tracker Calendar. La raison est, là encore, un changement de licence de la bibliothèque d'origine ; les fonctionnalités essentielles de planification sont préservées et la maintenabilité s'améliore. Côté fonctionnel, Tiki 29 introduit les invitations privées où la liste des participants reste masquée : seul l'organisateur voit la liste complète, les invités reçoivent leur invitation sans voir les autres convives, tout en conservant le RSVP et l'intégration calendrier — utile pour des invitations en nombre où l'on ne veut pas exposer les adresses.

Tiki 30 affine l'articulation entre email et calendrier via Cypht. Lorsqu'une invitation reçue par email est confirmée et ajoutée au calendrier, l'email d'origine est désormais archivé plutôt que supprimé, ce qui conserve l'invitation et ses pièces jointes pour référence ultérieure aux côtés de l'événement. Et lors de la création d'un événement à partir d'une invitation email, Tiki privilégie désormais une version HTML propre du corps du message (assainie pour la sécurité), ce qui donne des descriptions d'événement plus fidèles et évite les artefacts techniques des pièces jointes calendaires.
Point d'attention pour les administrateurs : l'ancien MiniCal (le mini-calendrier personnel historique) est déprécié et destiné à disparaître ; Tiki 29 a d'ailleurs introduit une commande calendar:minical:migrate pour basculer ces données vers l'infrastructure moderne de calendriers privés.

Articles

La brique CMS de Tiki, distincte des pages wiki : du contenu daté, publié, organisé par sujets (topics) et soumis à un circuit de validation (submissions) n'a pas connu de refonte majeure sur la série 27 → 30. C'est un module mature, et l'essentiel des évolutions le touche indirectement, via des améliorations transverses dont il bénéficie : le nouvel éditeur (Markdown/TOAST UI et WYSIWYG Summernote), l'accessibilité revue, la recherche, et les notifications.

Le changement le plus concret remonte à Tiki 27, avec l'introduction de la permission tiki_p_export_pdf, qui permet de contrôler finement qui peut générer le PDF d'un article. En pratique, on l'utilise surtout pour retirer cette capacité aux visiteurs anonymes : la génération de PDF est coûteuse en ressources, et les robots d'indexation en abusent volontiers, au point de peser sur la charge serveur. Pouvoir réserver l'export PDF aux utilisateurs enregistrés est un petit réglage qui évite de gros désagréments. Sur Tiki 30, la nouvelle file de tâches en arrière-plan (queue:process) bénéficie d'ailleurs à ce type d'opération, en déchargeant la génération de PDF hors des requêtes web.

Pour le reste, les articles profitent du soin général porté à la cohérence de l'interface d'administration au fil des versions, sans bouleversement de leur fonctionnement propre.

Articles natifs ou articles « maison » via trackers : un choix d'architecture

Il faut ici ouvrir une parenthèse qui dépasse le simple journal des versions, car elle conditionne la façon dont on lit l'évolution des articles.

Dans Tiki, le module Articles natif (avec ses topics, ses submissions, sa date de publication) n'est pas la seule manière de gérer du contenu éditorial. Beaucoup de sites un peu avancés gèrent en réalité leurs « articles » via des trackers : un tracker joue le rôle de table d'articles (titre, chapô, corps, date, auteur, catégorie, image à la une…), et l'affichage se construit avec les plugins de la famille List.

Le mécanisme est simple à décrire. La saisie se fait dans les trackers, la visualisation des articles via PluginList ou PluginTrackerList (avec tri, filtres, pagination, gabarit d'affichage), et le passage de la liste à la fiche détaillée via le paramètre d'URL qui transmet l'itemId à une page de détail. On obtient ainsi un système de publication entièrement sur mesure : structure de champs libre, workflow de validation par statut, droits fins par groupe, et présentation maîtrisée au pixel près — là où le module Articles impose son modèle de données.

Pourquoi c'est important dans le cadre de cette migration : c'est précisément l'approche par trackers qui capte tout le bénéfice des évolutions 27 → 30. Le module Articles natif évolue peu sur cette série (voir ci-dessus), mais si vous gérez votre contenu éditorial par trackers, vous héritez directement de tout ce qui a été décrit dans la section Trackers et la section Recherche : index InnoDB sans limite de champs, nouveaux types de champs, « Did You Mean ? » et recherche floue sur vos listes d'articles, galeries de fichiers par item pour les pièces jointes, etc. Autrement dit, la question « les articles ont-ils progressé ? » a deux réponses opposées selon votre architecture — modeste pour le module natif, substantielle pour l'approche tracker.

Cela ouvre aussi une piste : si un site est encore sur le module Articles natif et s'y sent à l'étroit (workflow rigide, champs figés), une migration de version est le bon moment pour réévaluer un passage vers une gestion par trackers, là où Tiki investit aujourd'hui le plus.

Blogs

Les blogs sont l'un des modules les plus stables de Tiki, et la série 27 → 30 ne leur apporte pas de nouveauté spécifique marquante. Cela ne veut pas dire qu'ils stagnent : comme les articles, ils héritent automatiquement des chantiers transverses qui comptent au quotidien — la modernisation des éditeurs (le collage de contenu mis en forme depuis un traitement de texte fonctionne mieux avec Summernote), la refonte de l'accessibilité (structure de titres, ARIA), l'amélioration de la recherche et des suggestions, et la préférence de notification sur ses propres commentaires introduite en Tiki 28.

Autrement dit, si votre site s'appuie sur les blogs, la valeur d'une migration ne se lit pas dans une liste de fonctionnalités « blog » mais dans la qualité d'usage générale qui remonte d'un cran à chaque version.

Forums

Le changement à retenir côté forums se situe dans Tiki 29, et il demande une action concrète de l'administrateur : la récupération des messages postés par email (le « mail-in » des forums) passe désormais par IMAP avec TLS, en remplacement du protocole POP3 historique — dont le support a été supprimé.

Sur le fond, c'est un bon changement : IMAP avec TLS offre un accès chiffré et reste compatible avec les fournisseurs de messagerie modernes, dont beaucoup ont commencé à fermer l'accès POP3 non chiffré. Mais il y a une conséquence opérationnelle à anticiper : IMAP ne supprime pas les messages de la boîte par défaut, contrairement au comportement POP3 où le message était typiquement retiré après récupération. Si vous utilisez le mail-in des forums, vous devez donc revoir les réglages de rétention de la boîte mail dédiée, faute de quoi elle se remplira indéfiniment et les mêmes messages risquent d'être retraités. C'est exactement le genre de détail qui se gère en cinq minutes quand on l'anticipe, et qui devient un incident quand on le découvre en production.
Pour le reste, les forums bénéficient des améliorations transverses (éditeur, recherche, accessibilité, notifications) sans refonte de leur logique propre.

Mail et webmail

La messagerie est l'un des axes stratégiques de Tiki depuis plusieurs versions, sous le mot d'ordre « l'email comme citoyen de première classe » : l'idée que la gestion des emails doit être aussi intégrée au reste de Tiki que le sont les pages wiki, les fichiers ou les trackers. Concrètement, cela passe par Cypht, le client webmail libre embarqué dans Tiki (un agrégateur capable de regrouper plusieurs boîtes), enrichi dans Tiki de fonctions qu'il n'a pas en solo, comme l'intégration calendrier (CalDAV) et le lien avec les trackers. Sur la série 27 → 30, le travail se répartit entre la mise à jour de la plomberie d'envoi et de lecture, et l'intégration de l'email dans les flux de travail.

Côté plomberie, deux changements importants pour les administrateurs. D'abord, Tiki 27 a fait passer Cypht de la branche 1.4 à la branche 2.0, avec son lot d'améliorations, et les versions suivantes ont continué la mise à niveau (Cypht 2.4.x en Tiki 29). Ensuite, et c'est le point à connaître pour les configurations personnalisées : Tiki 29 a remplacé la bibliothèque d'envoi d'emails. L'ancienne brique laminas-mail (héritée de l'époque Zend Framework) a été abandonnée par son éditeur ; Tiki l'a donc remplacée par symfony-mailer.

Dans le même mouvement, Tiki 29 a modernisé l'analyse des emails entrants (montée de version du parseur MIME pour une meilleure compatibilité PHP 8.2+ et une gestion plus fiable des en-têtes encodés et des pièces jointes).

Côté flux de travail, c'est là que la vision « email first-class citizen » devient tangible. Tiki 29 introduit une intégration intelligente entre la webmail Cypht et les trackers : à l'envoi d'un email, Tiki suggère automatiquement les éléments de tracker pertinents, et l'utilisateur peut choisir de classer l'email envoyé dans le dossier de l'élément concerné. L'email cesse ainsi de vivre dans une boîte isolée pour rejoindre le dossier du projet, du client ou du dossier de support auquel il se rapporte — un vrai gain de traçabilité. Cette brique pose aussi les fondations du routage automatique des réponses, via un champ « dossier email » et des règles Sieve, et s'articule avec la recherche par email déjà alimentée dans l'index unifié. Tiki 30 prolonge la logique côté calendrier : une invitation reçue par email et confirmée voit son message d'origine archivé plutôt que supprimé (l'invitation et ses pièces jointes restent disponibles aux côtés de l'événement), et les descriptions d'événements créés depuis un email privilégient désormais une version HTML propre et assainie.

Si votre usage de Tiki tourne autour de la collaboration projet ou de la relation client, c'est probablement le domaine où la valeur d'une migration vers Tiki 29/30 est la plus concrète, parce qu'il transforme la webmail d'un simple lecteur d'emails en pièce du dispositif collaboratif.

Plugins, nouvelles options et changements de technologie

Cette section regroupe ce qui touche aux briques techniques transverses : les nouveautés côté plugins (les extensions de syntaxe wiki qui ajoutent des fonctions dans les pages), les nouvelles options de configuration, et les changements de technologie sous le capot. C'est un point fort de Tiki à souligner pour votre lectorat : comme la quasi-totalité des fonctionnalités vit dans le cœur du logiciel, vous n'avez pas à attendre qu'un écosystème de plugins tiers se mette à jour avant de migrer — un atout déterminant face à des CMS où une montée de version est régulièrement bloquée par une extension non maintenue.

Nouveaux plugins et options

Tiki 29 introduit PluginFancyLink, qui génère un aperçu enrichi d'une URL directement dans la page (titre, description et image du contenu lié extraits automatiquement), activable via une préférence dédiée — pratique pour des pages de veille ou de curation. Tiki 30 continue dans cette veine avec PluginModel3DViewer (affichage d'objets 3D dans une page), des reflets d'image en CSS moderne via les options de PluginImg, et surtout un enrichissement attendu de PluginList, qui gère désormais le filtrage avancé avec une logique ET / OU / NON sur des sélections multiples — un vrai gain pour les sites qui s'appuient sur les listes de trackers (et donc, comme on l'a vu, pour la gestion d'articles par trackers). En remontant à Tiki 27, on trouve aussi l'arrivée de PluginList Sublist (sous-listes imbriquées) et la sortie de facettes pour PluginList et PluginCustomSearch, qui ont musclé les capacités de recherche présentée en page.

Changements de technologie sous le capot

C'est ici que se concentre la modernisation, largement amorcée par Tiki 27 (Smarty 5, nouveau système de build basé sur npm, PHPUnit 10). Tiki 28 a poursuivi en migrant les bibliothèques JavaScript et CSS vers ce nouveau système de build, et en ajoutant un mécanisme de validation de la version de Composer utilisée avec Tiki Manager, pour éviter les incidents liés à une version incompatible préinstallée sur le serveur. Tiki 29 a remplacé une série de dépendances vieillissantes : montée de Swiper (carrousels) de la version 3 à la 11 via npm, remplacement de PhantomJS/CasperJS par Chrome-php pour la navigation sans interface (utilisée pour l'export de diagrammes wiki, les instantanés de recherche et l'export de graphiques), et bascule du parseur d'emails entrants vers une version compatible PHP 8.2+. Tiki 30 a continué le rafraîchissement des briques (Converse.js 11 → 12 pour la messagerie instantanée, DOMPurify 2 → 3 pour l'assainissement HTML, Monolog 3 pour la journalisation) et anticipe la compatibilité avec PHP 8.4 et 8.5.

Point d'attention : Element Plus

Depuis Tiki 27/28, Tiki s'appuie de plus en plus sur la bibliothèque de composants d'interface Element Plus pour ses sélecteurs et widgets de saisie modernes. C'est plus joli et plus fonctionnel à l'usage, mais cela a une conséquence pour qui personnalise son site : ces composants sont plus difficiles à cibler en CSS ou en JavaScript que les anciens éléments de formulaire. Si votre site repose sur des personnalisations poussées de thème ou des scripts qui manipulent les champs, c'est un point à tester soigneusement lors de la migration. La question fait d'ailleurs l'objet d'une revue active côté développeurs (projet « Review all selectors and pickers »).

La file de tâches en arrière-plan

Dans Tiki 30, un système générique de file d'attente (commande queue:process) permet désormais de décharger les opérations longues — génération de PDF, création d'instances — hors des requêtes web, avec un suivi complet du cycle de vie des tâches (en attente, en cours, terminée, échouée) et des points d'accès API et ligne de commande. C'est une fondation discrète mais structurante, qui améliore la réactivité perçue des gros sites et ouvre la voie à des traitements asynchrones plus ambitieux dans les versions suivantes.

Sécurité et authentification

C'est l'un des domaines où la progression est la plus nette et la plus continue sur la série 27 → 30, et c'est un argument de migration à part entière. Rester sur une version qui ne reçoit plus que des correctifs de sécurité, c'est précisément se priver de ces renforcements. Tiki accorde depuis longtemps une grande importance à la sécurité et à la finesse de son système de permissions, qui se décline jusqu'au niveau de chaque fonctionnalité et de chaque objet du site.

L'authentification forte progresse à chaque version

Tiki 28 a ajouté la double authentification (2FA) par email, en complément de la 2FA par application type Google Authenticator, ce qui offre une alternative aux administrateurs sans imposer une application tierce.

Tiki 29 franchit une étape importante avec WebAuthn et les passkeys : la connexion sans mot de passe, via une clé matérielle, l'empreinte digitale ou la reconnaissance faciale de l'appareil. C'est aujourd'hui le standard de l'authentification forte, résistant au hameçonnage, et son arrivée dans Tiki met le CMS au niveau des attentes actuelles en matière de sécurité de connexion.

Tiki 30 industrialise la gestion de la 2FA pour les organisations. Là où les versions précédentes activaient la fonction, Tiki 30 la rend administrable à grande échelle. Les administrateurs peuvent désormais réinitialiser ou désactiver la 2FA d'un utilisateur — indispensable pour les scénarios de récupération de compte, quand quelqu'un perd son téléphone ou sa clé. L'enforcement de la 2FA devient configurable avec des périodes de grâce par groupe et par utilisateur (3, 7, 14 ou 30 jours par exemple), avec rappels affichés pendant le délai et notifications optionnelles aux utilisateurs qui ne l'ont pas encore activée. Une interface dédiée permet d'accorder, révoquer ou prolonger ces délais individuellement. Pour une organisation qui doit déployer la 2FA sur une large base d'utilisateurs sans bloquer tout le monde du jour au lendemain, c'est exactement l'outillage qui manquait.

Tiki 30 ajoute aussi la possibilité de verrouiller ou déverrouiller plusieurs comptes en lot depuis l'administration des utilisateurs, et un mécanisme expérimental de protection contre les attaques par force brute.

Durcissement côté serveur et navigateur

Tiki 30 introduit un jeu complet d'en-têtes de sécurité HTTP et un support CORS configurables directement depuis l'interface d'administration — de quoi appliquer les bonnes pratiques (politique de sécurité du contenu, protection contre le détournement de clic, contrôle des origines autorisées) sans éditer manuellement la configuration du serveur web.

Tiki 29 avait de son côté refondu le système de consentement aux cookies pour s'aligner sur les exigences du RGPD : l'utilisateur peut accepter, refuser ou personnaliser ses préférences via une boîte de dialogue, et ces choix sont mémorisés et synchronisés avec le compte. À noter, comme déjà signalé pour la webmail : cette refonte a changé de nombreux noms de préférences, donc à tester si vous gérez des configurations personnalisées.

Traçabilité et divulgation responsable. Tiki 29 a amélioré la journalisation via Monolog (notamment le suivi des échecs de connexion) et ajouté une commande security:generate qui crée un fichier security.txt standard dans le répertoire .well-known/ — le moyen normalisé de publier un contact sécurité et une politique de divulgation des vulnérabilités.

Tiki 28 avait par ailleurs renforcé la transparence de la fonction « changer d'utilisateur » (switch user) utilisée par les administrateurs : l'utilisateur concerné peut désormais être notifié quand un administrateur prend la main sur son compte, comportement activable selon la politique de l'organisation.

En somme, si un seul argument devait justifier de ne pas s'attarder sur une version en fin de support, ce serait celui-ci : la sécurité de Tiki s'est nettement renforcée entre 27 et 30, et ces protections ne se rétroportent pas.

Changements de prérequis

C'est le point qui conditionne la faisabilité technique de toute migration, et la bonne nouvelle domine : il n'y a pas de nouveau saut de prérequis majeur imposé entre Tiki 27 et Tiki 30.

Côté PHP, toute la série 27 → 30 vit dans le même intervalle : PHP 8.1 à 8.4, Tiki 30 préparant en plus la compatibilité avec PHP 8.5. Le saut difficile — le passage de PHP 7.4 à PHP 8.1, décrit par l'équipe comme la montée de version la plus ardue en vingt ans de projet — a été entièrement absorbé par Tiki 27. Autrement dit, si votre serveur tourne déjà en PHP 8.x, le plus dur est derrière vous et la route est dégagée. Le vrai blocage, le cas échéant, concerne les sites restés en PHP 7.4 : il faut alors traiter la mise à niveau du serveur en premier (pour mémoire, Tiki 24 LTS était la dernière version compatible PHP 7.4).

Côté base de données, le prérequis est MariaDB 10.5 ou supérieur, ou MySQL 8 ou supérieur, stable sur toute la série. Le point à intégrer à votre plan de test n'est pas un changement de version mais un changement de moteur de stockage : la bascule de l'index de recherche vers InnoDB introduite en Tiki 28, qui implique de reconstruire l'index après migration (voir la section Recherche).
Côté outillage enfin, depuis Tiki 27 les installations depuis le dépôt de code (git) reposent sur le système de build basé sur npm, et Tiki 28 a ajouté une vérification de la version de Composer utilisée. Si vous installez depuis un package classique, cela ne vous concerne pas ; si vous installez depuis git, anticipez cette étape de build. Un bon réflexe avant toute opération : passer le script « Server Check » fourni par Tiki, qui diagnostique en un coup d'œil la conformité de PHP, des extensions et de la base de données.

Que faire à partir d'ici

Voici la feuille de route que nous vous recommandons, dans l'ordre.

Vérifiez votre environnement serveur. Confirmez votre version de PHP (8.1 minimum, idéalement 8.2 ou 8.3) et de base de données (MariaDB 10.5+ ou MySQL 8+). C'est le prérequis qui commande tout le reste.

Migrez vers Tiki 29 dès maintenant, sur un environnement de test d'abord. C'est la version stable la plus récente, elle embarque les briques modernisées que Tiki 30 réutilise, et elle vous sort de la zone d'inconfort. La règle de migration de Tiki est d'ailleurs explicite. Quand on quitte une LTS, on vise la dernière version stable du moment, pas une autre vieille version.
Traitez les points de vigilance pendant cette migration. Tous ont été détaillés dans cet article.

  • Vos thèmes personnalisés, à recaler sur la version de Bootstrap utilisée par Tiki 27 et suivantes.
  • La conversion des clés de trackers (fieldID → permName), si vous avez du code ou des intégrations sur mesure.
  • La reconstruction de l'index de recherche après la bascule vers InnoDB.
  • Le changement d'éditeur WYSIWYG (CKEditor 4 → Summernote), qui justifie des tests approfondis si votre site l'utilise.
  • Le passage du mail-in des forums de POP3 vers IMAP, avec la rétention des boîtes à revoir.
  • Le renommage de nombreuses préférences (envoi d'emails passé à symfony-mailer, refonte du consentement aux cookies), si vous pilotez des configurations personnalisées.

Tout cela prépare votre Tiki à un passage sans heurt vers Tiki 30 LTS.
Tiki 30 est attendue pour l'été 2026. Comme pour chaque version, nous vous recommandons de lui laisser le temps de mûrir et de viser la migration 29 → 30.1 ou 30.2, une fois sorties les premières versions de maintenance qui confirment sa stabilité. Comme Tiki 30 est une LTS « de raffinement » et non de rupture, cette dernière étape sera nettement plus douce que ne l'a été le grand chantier de Tiki 27.

Vous voilà prêt pour la mise à jour de votre Tiki. Selon votre configuration, plusieurs chemins s'offrent à vous. La mise à jour automatisée via les scripts de votre hébergeur pour les petits sites, le package de release, ou l'installation via Git comme nous le faisons pour les projets sérieux. Si vous ne savez pas par où commencer, vous pouvez chercher un consultant sur tiki.org/Consultants, ou bien sûr faire appel à notre service de support Tiki.

Pour aller plus loin : les sources officielles

Notes de version (documentation communautaire)
Tiki 27 - Tiki 28 - Tiki 29 - Tiki 30

Pages de développement (détail technique et commits)
dev Tiki 27 - dev Tiki 28 - dev Tiki 29 - dev Tiki 30

Dépôt de code source (GitLab)
Tiki sur GitLab - Commits 27.x - Commits 28.x - Commits 29.x - Commits 30.x

Cycle de vie
Tiki Lifecycle