Prêt pour la mise à jour

Vous choisissez la version visée, de la version majeure suivante jusqu’à la 24.0, et le PHP prévu après la mise à jour. Vous cliquez sur Lancer la vérification. Le module lit votre installation sans rien modifier et rend un rapport.

Le code de vos modules externes

C’est la partie principale du module. Le code de chaque module externe est lu fichier par fichier, sans être exécuté, et confronté aux changements de chaque version du chemin, pas seulement de la version visée :

• fonctions, classes, méthodes, propriétés, constantes et fichiers du cœur supprimés ;
• méthodes surchargées devenues incompatibles avec celles de Dolibarr ;
• appels avec moins d’arguments que ce que Dolibarr exige désormais ;
• colonnes et tables supprimées dans les requêtes SQL du module ;
• hooks et événements de trigger qui ne sont plus appelés ;
• fonctions, constantes et syntaxes refusées par le PHP prévu.

Chaque constat donne le fichier, la ligne, la version où ça casse, un degré de certitude et, quand il est connu, le remplacement. Chaque module reçoit un taux de couverture : la part des appels réellement vérifiés. Le code chiffré (ionCube, SourceGuardian, Zend Guard) est signalé comme non vérifiable.

Les neuf autres familles de contrôles

Le rapport

Il commence par une réponse en une ligne — prêt, presque prêt ou pas encore prêt — puis la version la plus haute atteignable sans rien toucher, le chemin étape par étape et le plan dans l’ordre. Il dit aussi si la version installée et la version visée reçoivent encore les correctifs de sécurité, ce qu’il faut sauvegarder et quelle étape réécrit le plus de données.

Chaque constat a un niveau — sans problème, à vérifier, bloquant ou non vérifiable — avec ce qu’il faut faire et la source de la règle.

Le rapport se télécharge en HTML ou en Markdown. L’option anonymiser masque le domaine, les chemins, le nom de la société et l’identifiant de l’utilisateur. Pour chaque module en cause, le bouton Rapport pour l’éditeur produit un fichier à lui envoyer : fichiers, lignes, correctif connu, rien sur votre société ni votre serveur.

Ce que le rapport ne peut pas garantir

Le rapport le dit lui-même, en bas de page : il réduit les risques connus, il ne garantit pas le succès de la mise à jour. Il ne prouve pas qu’un module externe fonctionnera — seul un test sur une copie le peut —, ne prévoit ni les bugs de la version visée ni le comportement des scripts de migration face à vos données, et ne vérifie pas qu’une sauvegarde est restaurable.

L’analyse du code est bornée : 60 secondes au total, 30 secondes au plus par module. Les fichiers de plus de 2 Mo et les dossiers vendor, node_modules et includes des modules ne sont pas lus, et le rapport le signale. Les versions visées s’arrêtent à la 24.0 : les données de référence du module sont à jour au 25 septembre 2026.

L’outil se trouve sous AccueilOutils d’administrationPrêt pour la mise à jour.

Le rapport d’une instance de test en 18.0.9 qui vise la 24.0 : « Pas encore prêt : 1 action(s) avant de monter ». Le module fictif DemoFutur casse dès la 20.0 : on peut monter jusqu’à la 19.0.4 sans rien toucher. Suivent la ligne sécurité — la 18.0 ne reçoit plus de correctifs —, le chemin de la 18.0 à la 24.0 et le plan : obtenir de l’éditeur une version compatible, puis passer en 18.0.10 et monter une étape à la fois.

L’écran de départ : la version visée, 24.0 (24.0.1), le PHP prévu après la mise à jour, et la case « Intégrité des fichiers du cœur ».

Le bloc « Vos modules ». Pour DemoFutur, une classe supprimée en 20.0 et une fonction supprimée en 23.0, avec le fichier, la ligne et le remplacement, « code analysé à 100 % (2 appels vérifiés sur 2) » et le bouton « Rapport pour l’éditeur ». DemoCasse, inactif et incompatible, est à supprimer.

• Réservé aux administrateurs. Le menu et chaque page vérifient que l’utilisateur est administrateur de Dolibarr ; un autre utilisateur reçoit « Accès refusé ». Le module n’a pas de droit dédié.
• Lecture seule. La vérification n’écrit rien, ni en base ni sur le disque. Pendant les tests, une empreinte complète de la base et des fichiers a été prise avant et après une vérification : elle était identique.
• Jeton anti-CSRF sur chaque action : vérification, téléchargements, rapport pour l’éditeur.
• Aucun secret affiché ni exporté. Pour conf.php, le module dit seulement si une clé est présente, jamais sa valeur.
• Aucune commande lancée. Les réparations, comme l’harmonisation de l’encodage des tables, sont indiquées, jamais exécutées.
• Une seule connexion possible. La case « Intégrité des fichiers du cœur » n’est cochée d’office que si la signature officielle de votre version est déjà dans install/ : la comparaison se fait alors sans réseau. Sinon elle reste décochée, et c’est la cocher qui autorise le téléchargement de la signature depuis dolibarr.org. Case décochée, le module ne se connecte à rien.

• Le dossier dolixmaj, en clair, sous licence GPL v3 ou ultérieure : la page de l’outil, une page « À propos » sans réglage, les classes de vérification et d’analyse du code, et les données de référence Dolibarr 16.0 à 24.0.2 (data/).
• Les traductions présentes dans langs/ : français (fr_FR), anglais (en_US) et allemand (de_DE).
• Un README.md et un ChangeLog.md.
• Dolibarr 16.0 minimum, PHP 7.0 minimum, MySQL/MariaDB et PostgreSQL. Installé et exécuté sur 16.0.5, 17.0.4, 18.0.9, 18.0.10, 19.0.4, 20.0.4, 21.0.4, 22.0.5, 23.0.4, 24.0.0, 24.0.1 et 24.0.2.

• Aucune table n’est créée, aucun réglage n’est enregistré. Seule l’activation du module enregistre, comme pour n’importe quel module, son état et son menu.
• Rien n’est conservé sur le serveur : le rapport est recalculé à chaque demande, les téléchargements sont générés à la volée.
• Les rapports téléchargés restent sur votre poste. Anonymisés, ils ne contiennent ni le domaine, ni les chemins, ni le nom de la société, ni l’identifiant de l’utilisateur.
• À la désactivation, le menu disparaît. Il n’y a rien à nettoyer en base.