Automatiser planning dans Dolibarr : Plan d’action avec une approche sécurité

Version 1.0 – novembre 2025 —

1. Introduction

Dolibarr est un ERP/CRM open‑source très apprécié pour sa simplicité d’utilisation et son extensibilité. L’une des fonctionnalités les plus demandées par les utilisateurs est la planification automatisée (calendrier de tâches, rappel de factures, génération de rapports périodiques, etc.).

Cependant, l’automatisation expose également de nouveaux vecteurs de vulnérabilités : exécution de scripts non autorisés, fuite de données sensibles, modifications non traçables, etc. Ce document propose un plan d’action détaillé pour mettre en place un mécanisme de planification robuste dans Dolibarr, tout en garantissant une sécurité renforcée à chaque étape.

2. Contextes et enjeux

Enjeu	Risques si non contrôlé	Bénéfices attendus
Fiabilité du planning	Oublis de factures, retards clients, perte de revenus	Amélioration de la cadence opérationnelle, réduction du travail manuel
Sécurité des données	Accès non autorisé aux commandes, factures ou contacts	Confidentialité préservée, conformité RGPD, auditabilité
Traçabilité	Impossibilité de reconstituer les actions automatisées	Historique complet pour audit interne ou externe
Interopérabilité	Conflits avec plugins ou upgrades futurs	Stabilité sur le long terme

3. Principes de sécurité à appliquer

Principe du moindre privilège – Chaque composant (cron, script PHP, module externe) ne doit disposer que des droits strictement nécessaires.

Ségrégation des environnements – Production, pré‑production et développement doivent être séparés avec des configurations de sécurité différentes.

Chiffrement des communications – Utiliser HTTPS et, si besoin, TLS pour les appels API ou les webhooks.

Journalisation auditable – Toutes les actions planifiées doivent être enregistrées avec un horodatage, un identifiant d’utilisateur et le résultat de l’opération.

Gestion des secrets – Stockage des clés API, mots de passe ou jetons dans un gestionnaire de secrets (ex. : HashiCorp Vault, AWS Secrets Manager) et non dans le code source.

Validation des entrées – Filtrage strict des paramètres passés à des scripts automatisés pour éviter les injections (SQL, XSS, LFI).

Contrôle de version et revues de code – Tous les scripts d’automatisation sont versionnés (Git) et soumis à une revue par pair avant déploiement.

4. Plan d’action détaillé

4.1. Analyse préalable

Action	Description	Responsable	Sortie attendue
Recenser les besoins de planification	Identifier les processus (ex. : rappel de Factures, génération de rapports, sauvegarde)	Chef de projet	Liste fonctionnelle détaillée
Cartographier les dépendances	Déterminer les modules Dolibarr ou tables de la base de données concernées	Architecte	Diagramme d’interaction
Évaluer le niveau de criticité	Classer chaque scénario (bas, moyen, élevé)	Responsable sécurité	Matrice de priorisation

Livrable : Document de spécifications fonctionnelles & sécurité (PDF + maquettes).

4.2. Choix de l’architecture d’automatisation | Option | Avantages | Inconvénients | Sécurité |

Recommandation : Utiliser un script PHP autonome exécuté par cron intégré à l’infrastructure serveur, avec la mise en place d’un conteneur Docker pour la stabilité et l’isolation.

4.3. Implémentation technique

4.3.1. Création du conteneur Docker

FROM php:8.2-fpm-alpine
# 1. Dépendances PHP

RUN apk add --no-cache git unzip && \

    docker-php-ext-install pdo_mysql
# 2. Installation de Dolibarr (version stable)

ENV DOLIBARR_VERSION=8.0.3

RUN wget -qO- https://github.com/Dolibarr/dolibarr/archive/refs/tags/${DOLIBARR_VERSION}.tar.gz | \

    tar xz -C /var/www/ && \

    mv /var/www/dolibarr-${DOLIBARR_VERSION} /var/www/dolibarr && \

    chown -R www-data:www-data /var/www/dolibarr
WORKDIR /var/www/dolibarr
# 3. Copie du script d’automatisation

COPY src/auto_planif.php /var/www/dolibarr/src/auto_planif.php
# 4. Permissions

RUN chmod 750 src/auto_planif.php && \

    chown www-data:www-data src/auto_planif.php
# 5. Expose le port HTTP/HTTPS (optionnel)

EXPOSE 80 443
CMD ["php-fpm"]

Points de sécurité :

Le conteneur tourne sous l’utilisateur www-data.

Seul le fichier auto_planif.php possède les droits d’exécution (750).

Le code source du conteneur est versionné dans un dépôt privé avec contrôle d’accès restreint.

4.3.2. Script d’automatisation (`auto_planif.php`)

<?php

declare(strict_types=1);
/**

 * Script de planification sécurisée pour Dolibarr.

 * - Gestion des rappels de factures.

 * - Génération de rapports PDF mensuels.

 * - Nettoyage des tables temporaires.

 *

 * Toutes les actions sont journalisées dans /var/log/dolibarr/auto_planif.log.

 */
require __DIR__.'/../../bootstrap.php';   // Charge l'autoloader Dolibarr

require_once '/etc/dolibarr/conf/localconf.php'; // Contient la connexion DB
// ==== 1. Validation du contexte ====

if (!defined('MY_CONSTANT')) {

    // Empêche l'exécution directe du script depuis le web

    http_response_code(403);

    exit('Accès interdit');

}
// ==== 2. Authentification & élévation de privilèges ====

$security->validateSSO();               // Vérifie le token SSO du serveur

if ($security->isAdmin() === false) {

    // Seuls les administrateurs système peuvent déclencher le script

    error_log("[".date('Y-m-d H:i:s')."] ERREUR - Accès non autorisé");

    exit('Permission refusée');

}
// ==== 3. Configuration des tâches ====

$tasks = [

    [

        'name'      => 'Rappel factures à échéance',

        'query'     => 'SELECT id FROM ll_facture WHERE date_due = CURDATE() + INTERVAL 3 DAY',

        'action'    => function($id){ $this->sendReminder($id); },

        'frequency' => 'daily'

    ],

    [

        'name'      => 'Rapport mensuel ventes',

        'query'     => 'SELECT * FROM ll_pos WHERE sale_date >= DATE_SUB(CURDATE(), INTERVAL 1 MONTH)',

        'action'    => function(){ $this->generateReport(); },

        'frequency' => 'monthly'

    ],

    // ... autres tâches

];
// ==== 4. Exécution filtrée selon fréquence ====

foreach ($tasks as $task) {

    if ($this->isTaskDue($task['frequency'])) {

        try {

            // 4.1. Exécution requête préparée

            $db->begin();

            $res = $db->query($task['query']);

            while ($obj = $db->fetchObject($res)) {

                call_user_func($task['action'], $obj->id);

            }

            $db->commit();

            // 4.2. Journalisation            $log->addLog('AUTO_PLANIF', $task['name'], $security->getUserID(), 'SUCCESS');

        } catch (Exception $e) {

            $db->rollback();

            $log->addLog('AUTO_PLANIF', $task['name'], $security->getUserID(), 'FAIL', $e->getMessage());

            // gestion de l'alerte (mail ou ticket)

            $alert->raise($e);

        }

    }

}
// ==== 5. Nettoyage sécurisé des fichiers temporaires ====

$tmpPath = sys_get_temp_dir().'/dolibarr_auto_';

foreach (glob($tmpPath.'*') as $file) {

    @unlink($file);

}

?>

Mécanismes de sécurité intégrés :

Vérification d’un constante définie (MY_CONSTANT) afin d’empêcher l’appel direct depuis le navigateur.

Contrôle d’accès admin‑only ($security->isAdmin()).

Utilisation de requêtes préparées implicitement via le wrapper $db->query.

Journalisation centralisée ($log->addLog) avec fourchette d’audit.

Gestion des transactions (begin/commit/rollback) pour garantir l’intégrité des modifications. #### 4.3.3. Planification via crontab

# Utilisateur dédié (ex: dolibarr_sched)

# Edit crontab avec sudo -u dolibarr_sched crontab -e

0 2 * * * docker exec dolibarr_container php /var/www/dolibarr/src/auto_planif.php >> /var/log/dolibarr/auto_planif.log 2>&1

Répétition : toutes les 2 h (heure basse pour limiter l’impact).

Redirection des sorties vers un fichier de log dédié, accessible uniquement à root et www-data.

4.4. Hardening du serveur

Action	Méthode	Résultat attendu
Isoler le conteneur	Utiliser `seccomp` et `--cap-drop=ALL` lors du `docker run`	Limite les privilèges système
Restreindre les accès réseau	`--network none` ou `ipset` pour bloquer les sorties externes non autorisées	Empêche les liaisons sortantes non prévues
Activer SELinux/AppArmor	`setenforce 1` (SELinux) ou profils AppArmor spécifiques au conteneur	Contrôle d’accès obligatoire au niveau du kernel
Mettre à jour les dépendances	`docker pull php:8.2-fpm-alpine --security‑latest` chaque mois	Corrige les vulnérabilités connues
Scans de vulnérabilité	`docker scan` ou `Trivy` intégré au pipeline CI	Détection précoce de CVE dans l’image
Rotation des clés API	Utiliser HashiCorp Vault pour renouveler les jetons de service toutes les 30 jours	Réduction de la surface d’exposition

4.5. Gestion des journaux & audit

Log de planification (/var/log/dolibarr/auto_planif.log) – chaque ligne possède le format : « `
[YYYY-MM-DD HH:MM:SS] ACTION_ID USER_ID STATUS MESSAGE

Centralisation – Forwarder les logs vers un syslog ou un ELK avec chiffrement TLS.

Alerting – Utiliser Prometheus Alertmanager pour déclencher une alerte si le statut FAIL apparaît plus de 3 fois consécutives.

Archive – Conserver les logs sur 90 jours dans un bucket S3 avec politique de versioning et chiffrement SSE‑AES256.

4.6. Processus de revue & mise à jour

Étape	Description	Fréquence
Revue de code	Analyse statique (SonarQube), tests unitaires, validation du modèle de menace	À chaque modification de script
Test en pré‑prod	Déploiement du conteneur sur un environnement répliqué, exécution de scénarios de charge	Mensuel
Pentest ciblé	Scan externe (Nessus) et interne (OWASP ZAP) sur les endpoints exposés	Trimestriel
Audit de sécurité	Vérification des configurations Docker, des permissions système, du chiffrement	Semestriel
Mise à jour des dépendances	Pull des dernières images de base, mise à jour du module Dolibarr	Tous les 6 mois ou à chaque CVE critique

5. Bonnes pratiques complémentaires

Sauvegarde automatisée : Avant toute exécution de script modifiant la base, exécuter mysqldump --single-transaction et le placer dans un répertoire versionné.

Déploiement blue‑green : Utiliser deux conteneurs (v1 et v2) pour éviter les ruptures de service pendant le upgrade.

Notification des utilisateurs : Envoyer un e‑mail (ou une notification Slack) avant l’exécution d’une tâche sensible (ex. : paiementmass).

Détection d’anomalies : Analyser les fréquences d’appels anormales via fail2ban et bloquer l’IP en cas de comportement suspect.

6. Conclusion

L’automatisation du planning dans Dolibarr est un levier stratégique pour augmenter l’efficacité opérationnelle tout en réduisant les risques d’erreur humaine. En suivant le plan d’action présenté :

Analyse fonctionnelle et cartographie des dépendances,

Choix d’une architecture containerisée et isolée, 3. Implémentation d’un script PHP autonome avec journalisation et gestion des transactions,

Mise en place de politiques de sécurité strictes (principe du moindre privilège, chiffrement, journalisation auditable),

Hardening du serveur et processus de revue continue,

vous disposerez d’un système de planification fiable, traçable et résilient face aux menaces actuelles.

À retenir : la sécurité n’est pas un ajout tardif, elle doit être intégrée dès la conception. En combinant les bonnes pratiques de développement, de déploiement et de supervision, vous transformerez chaque tâche automatisée en un processus sécurisé par défaut.

Annexes

A. Modèle de log (JSON)

{

  "timestamp":"2025-11-03T08:15:22Z",

  "event":"AUTO_PLANIF",

  "task":"Rappel factures à échéance",

  "status":"SUCCESS",

  "user_id":7,

  "message":"Rappel envoyé à client#1234",

  "trace_id":"c3f9a1b2-5d7e-4f90-9c8e-2b6b1e9a7d34"

}

B. Exemple de règle `fail2ban`

« `ini[auto-planif]
enabled = truefilter = auto-planif
action = iptables-multiport[name=auto-planif, port="80,443"]
logpath = /var/log/dolibarr/auto_planif.log
bantime = 3600
findtime = 600
maxretry = 5


#### C. Checklist de sécurité avant chaque déploiement  
- [ ] Code revu et signé par au moins deux développeurs.  

- [ ] Scans de vulnérabilité_passés (Docker, PHP, SQL).  

- [ ] Tests d’intégrité des données (rollback simulée).  

- [ ] Logs mis à jour et forwardés vers le SIEM.  - [ ] Secrets stockés dans le gestionnaire Vault, pas dans le repo Git.  - [ ] Plan de rollback documenté et testé.  
---
*Prepared by the Dolibarr Security & Automation Working Group – November 2025*

Automatiser planning dans Dolibarr : Plan d’action avec une approche sécurité

1. Introduction

2. Contextes et enjeux

3. Principes de sécurité à appliquer

4. Plan d’action détaillé

4.1. Analyse préalable

4.2. Choix de l’architecture d’automatisation | Option | Avantages | Inconvénients | Sécurité |

4.3. Implémentation technique

4.3.1. Création du conteneur Docker

4.3.2. Script d’automatisation (`auto_planif.php`)

4.4. Hardening du serveur

4.5. Gestion des journaux & audit

4.6. Processus de revue & mise à jour

5. Bonnes pratiques complémentaires

6. Conclusion

Annexes

A. Modèle de log (JSON)

B. Exemple de règle `fail2ban`

Dolibarr ERP : Astuces et conseils dʼexperts

Optimisez votre entreprise avec Dolibarr et la gestion des relations clients

Dolibarr + Make.com : POS pour passer à l’échelle

Le guide ultime pour comprendre Dolibarr multi-utilisateurs

Dolibarr et la gestion des stocks : Guide complet pour débutants

Les secrets d’une gestion réussie avec Dolibarr et la gestion de la facturation

1. Introduction

2. Contextes et enjeux

3. Principes de sécurité à appliquer

4. Plan d’action détaillé

4.1. Analyse préalable

4.2. Choix de l’architecture d’automatisation | Option | Avantages | Inconvénients | Sécurité |

4.3. Implémentation technique

4.3.1. Création du conteneur Docker

4.3.2. Script d’automatisation (auto_planif.php)

4.4. Hardening du serveur

4.5. Gestion des journaux & audit

4.6. Processus de revue & mise à jour

5. Bonnes pratiques complémentaires

6. Conclusion

Annexes

A. Modèle de log (JSON)

B. Exemple de règle fail2ban

Publications similaires

4.3.2. Script d’automatisation (`auto_planif.php`)

B. Exemple de règle `fail2ban`