NexTool Solutions

FormCreator a été, pendant des années, le plugin le plus installé de GLPI - et dans GLPI 11 il cesse d'exister en tant que plugin. La question n'est plus "lequel est meilleur", mais une question opérationnelle : sur quelle version êtes-vous, et comment amener les formulaires déjà en production vers le nouveau module natif sans casser le catalogue de services.

Ce qui a changé de GLPI 10 à GLPI 11

Sur GLPI 9 et 10, formulaire personnalisé est synonyme de FormCreator : un plugin communautaire (maintenu par Teclib) qui fournit un catalogue de services, des champs conditionnels, des sections et la génération automatique de ticket à partir des réponses. La dernière ligne standalone est la 2.13.x - à partir de là, le développement du plugin s'est arrêté.

Sur GLPI 11, cette fonctionnalité est devenue un module du cœur : le menu Formulaires, avec un éditeur visuel, des sections, des questions conditionnelles et des destinations (ce que le formulaire génère - ticket ou changement). FormCreator standalone ne fonctionne pas sur 11. À sa place, il n'existe qu'un plugin de transition, le Formcreator Migration Tool (ligne 3.0.x), dont la seule mission est d'amener les anciens formulaires vers le module natif puis de déclarer FormCreator en fin de vie (EOL).

Comparatif direct

La migration n'est pas un bouton magique

Il existe bien une migration officielle - et cela démonte le mythe selon lequel "il faut tout recréer à la main". Le chemin est assisté : mettez à jour FormCreator en 2.13.10 ou plus récent encore sous GLPI 10, montez GLPI 11 avec le Migration Tool, vérifiez le volume dans Outils > Formcreator EOL Info et lancez la migration en ligne de commande.

# 1) Encore sous GLPI 10 : mettez a jour FormCreator en version 2.13.10 ou plus recent.
# 2) Montez GLPI 11 et installez le "Formcreator Migration Tool" (plugin 3.0.x).
# 3) Verifiez le volume a migrer dans le menu Outils, entree Formcreator EOL Info.
# 4) Lancez la migration en CLI, en tant qu'utilisateur du serveur web
#    (Debian/Ubuntu utilise www-data ; RHEL/CentOS utilise apache) :
sudo -u www-data php bin/console migration:formcreator_plugin_to_core

# Ordre correct lorsque plusieurs plugins legacy coexistent dans le meme environnement :
# Generic Objects, puis Fields et enfin FormCreator.

Avant de lancer quoi que ce soit, dimensionnez le travail. Un inventaire rapide dans la base indique combien de formulaires, de questions et de cibles vous aurez à vérifier ensuite - et lesquels sont les plus lourds :

-- Inventaire AVANT de migrer : lancez-le sur la base GLPI (10, ou 11 avec le
-- Migration Tool installe) pour dimensionner la verification post-migration.
SELECT
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_forms WHERE is_deleted = 0) AS formulaires,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_sections)                   AS sections,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_questions)                  AS questions,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_targettickets)              AS cibles_ticket;

-- Les formulaires avec le plus de questions sont ceux qui demandent le plus de verification
SELECT f.name AS formulaire, COUNT(q.id) AS questions
FROM glpi_plugin_formcreator_forms f
LEFT JOIN glpi_plugin_formcreator_sections s
  ON s.plugin_formcreator_forms_id = f.id
LEFT JOIN glpi_plugin_formcreator_questions q
  ON q.plugin_formcreator_sections_id = s.id
WHERE f.is_deleted = 0
GROUP BY f.id, f.name
ORDER BY questions DESC;

Ce que l'outil migre bien, c'est la structure et le contenu : sections, questions et types de champ. Là où il demande une vérification humaine, c'est la logique de routage - FormCreator utilisait le "target ticket" pour définir la catégorie, le modèle, le groupe et les acteurs du ticket généré ; en natif cela devient des destinations, et l'import signale les dépendances manquantes sur la cible (entité, catégorie) à mapper avant de conclure.

Le compromis qui apparaît en maintenance

Quand on maintient des parcs GLPI pour des clients, l'erreur la plus courante n'est pas technique, c'est une erreur d'attente : quelqu'un lance la commande de migration, les formulaires apparaissent dans le nouveau menu et l'équipe considère la tâche terminée. Elle ne l'est pas. Ce qui migre, c'est la coquille ; le cœur - quel ticket est ouvert, dans quelle catégorie, pour quel groupe, avec quel modèle - c'est justement ce qui exige une vérification. C'est pourquoi nous migrons toujours d'abord en recette, nous soumettons un ticket de test par formulaire et comparons le routage au comportement de l'ancien FormCreator, champ par champ.

Deux détails piègent ceux qui font cela pour la première fois. D'abord : les tables glpi_plugin_formcreator_* restent dans la base après la migration - rien n'est supprimé, elles deviennent une source de lecture/EOL et ne disparaissent pas, donc "tout a disparu" n'est souvent que le menu qui a bougé. Ensuite : les formulaires natifs reçoivent de nouveaux IDs (et UUIDs), donc tout lien direct, favori du portail ou raccourci de self-service qui pointait vers un formulaire FormCreator cesse de fonctionner et doit être repointé. Et il y a le prérequis silencieux : si FormCreator est dans une version antérieure à 2.13.10, le Migration Tool ne voit tout simplement pas les formulaires - mettre à jour avant tout, c'est ce qui évite la migration "vide".

Verdict par scénario

Restez sur FormCreator quand l'environnement est GLPI 9 ou 10 et qu'aucune migration vers 11 n'est à l'horizon proche. Sur ces versions, c'est l'option mature et sans substitut pour un catalogue de services et des formulaires personnalisés. Conseil pratique : gardez-le en 2.13.10 ou plus récent même sans migrer maintenant - c'est ce qui laisse la porte de la migration ouverte quand 11 arrivera.

Utilisez les formulaires natifs quand vous êtes sur GLPI 11 (ou sur le point de migrer). Il n'y a pas de décision à prendre ici : FormCreator standalone ne fonctionne pas sur 11, et le module natif est la voie - aucun plugin à gérer à la mise à niveau, avec export/import de formulaires entre environnements en JSON (ce que FormCreator n'a jamais fait nativement) et réconciliation des dépendances sur la cible.

En migrant de 10 vers 11, utilisez l'outil officiel mais traitez cela comme un projet, pas comme une commande : inventoriez les formulaires, dimensionnez la vérification selon le nombre de questions et de conditions, migrez en recette, validez le routage de chaque formulaire et ne promouvez qu'ensuite. Si plusieurs plugins legacy coexistent, respectez l'ordre indiqué par la documentation elle-même : Generic Objects, puis Fields, puis FormCreator.

Coût et effort

La licence n'est pas l'axe de la décision : FormCreator et les formulaires natifs sont gratuits, et sur 11 le natif est déjà dans le cœur. Le vrai coût est celui de la migration et de la vérification. La partie automatique - lancer bin/console - prend de quelques minutes à quelques dizaines de minutes selon le volume. La partie qui consomme du temps humain, c'est valider le routage et reconstruire la logique de destination qui n'est pas passée 1:1. Comme fourchette honnête : pour quelques formulaires simples, toute la migration tient en une après-midi ; pour des dizaines de formulaires avec beaucoup de conditions, d'acteurs et de modèles, prévoyez des jours de vérification en recette avant la mise en production.

Chez NexTool, nous déployons et maintenons GLPI pour des clients sur les deux générations et nous conduisons la migration de FormCreator vers les formulaires natifs sans faire tomber le catalogue de services. Si vous quittez GLPI 10 et ne voulez pas découvrir en production ce que la migration n'a pas amené, nos projets de déploiement et de migration couvrent ce chemin de bout en bout.

Révisé par l'équipe NexTool Solutions.