Automatiser des tâches avec Drupal

Imports périodiques, ETL léger et intégration CRM / ERP / marketing automation

Drupal est souvent perçu comme un CMS orienté contenu. Techniquement, c’est aussi un framework d’automatisation robuste, capable de gérer des imports périodiques, des flux ETL légers et des intégrations complexes avec des systèmes tiers (CRM, ERP, marketing automation).

Cet article se concentre sur les mécanismes essentiels, les patterns éprouvés et les choix techniques recommandés, jusqu’à l’intégration des systèmes externes.

1. Typologie des automatisations côté Drupal

Avant d’implémenter quoi que ce soit, il est essentiel d’identifier le rôle exact de Drupal dans le flux.

Cas d’usage fréquents

• Imports périodiques (XML, CSV, JSON, API REST)
• Synchronisation de données (one-way ou bi-directionnelle)
• Enrichissement et transformation de données
• Déclenchement d’actions automatisées
• Exposition d’APIs métiers

Drupal peut agir comme :

• Consumer : il récupère des données
• Processor : il transforme la donnée
• Producer : il expose ou pousse la donnée

Dans beaucoup de projets, Drupal remplit les trois rôles simultanément.

2. Les fondations techniques côté Drupal

2.1 Les limites du Cron Drupal natif

Le cron Drupal (hook_cron()) est inadapté aux automatisations sérieuses :

• fréquence non maîtrisée
• pas de parallélisme
• pas de reprise après échec
• dépendance à l’exécution interne

Il doit être considéré uniquement pour :

• des tâches légères
• sans enjeu métier critique

2.2 La Queue API : brique centrale de l’automatisation

La Queue API est indispensable pour toute tâche automatisée fiable.

Principe :

• une unité métier = un item de queue
• traitement asynchrone
• reprise automatique
• exécution contrôlée

$queue = \Drupal::queue('my_custom_import');
$queue->createItem($data);

Avantages :

• découplage ingestion / traitement
• meilleure tolérance aux erreurs
• scalabilité horizontale
• compatibilité cron / Drush

Toute automatisation non basée sur une queue est un anti-pattern.

2.3 Drush comme point d’entrée unique

Toute tâche automatisée doit être exécutable via Drush :

drush my-module:run-import

Pourquoi :

• planification via cron système
• exécution manuelle possible
• intégration CI/CD
• gestion des retours (exit codes)

Règle simple :

Si une automatisation n’est pas déclenchable par Drush, elle n’est pas industrialisable.

3. Imports périodiques : architecture recommandée

Pattern technique standard

1. Récupération de la source
   (API, SFTP, stockage externe, fichier)
2. Stockage temporaire (fichier ou table intermédiaire)
3. Découpage en unités métiers
4. Envoi en queue
5. Traitement unitaire
6. Mapping vers les entités Drupal
7. Persistance
8. Logging et supervision

Ce découpage permet :

• une meilleure observabilité
• des retries ciblés
• une gestion fine des erreurs

3.1 Pourquoi éviter Migrate API pour les imports récurrents

La Migrate API est très adaptée pour :

• les migrations initiales
• les reprises ponctuelles
• les imports structurés et figés

Mais elle est peu adaptée pour :

• synchronisations quotidiennes
• flux évolutifs
• volumes variables
• logiques métiers complexes
• reprises partielles contrôlées

Pour des imports périodiques :

➡️ Queue API + code métier dédié

4. ETL léger avec Drupal

Drupal peut jouer le rôle d’un ETL léger, à condition de rester dans un périmètre maîtrisé.

Transformations typiques

• normalisation de formats (dates, devises, codes)
• mapping métier (statuts, catégories, taxonomies)
• règles conditionnelles
• enrichissement via API secondaire
• déduplication simple

Exemple :

if ($data['status'] === 'ACTIVE' && $data['score'] >= 80) {
  $entity->set('field_level', 'premium');
}

Limites à ne pas dépasser :

• agrégations complexes
• jointures multi-sources lourdes
• calculs analytiques

Dans ces cas :
➡️ externaliser vers un ETL dédié (Airflow, Talend, etc.)

5. Intégration CRM / ERP / marketing automation

5.1 Modèles d’intégration courants

Le choix dépend :

• du système maître de la donnée
• de la volumétrie
• de la criticité métier

5.2 Drupal comme backend métier exposé

Dans de nombreux projets :

• Drupal est le référentiel fonctionnel
• le CRM ou l’ERP est consommateur

Exemples d’écosystèmes intégrés :

• HubSpot
• Salesforce
• ERP propriétaires
• plateformes marketing automation

Bonnes pratiques techniques :

• authentification OAuth2 ou JWT
• versionnement des endpoints
• payloads contractuels
• validation stricte des entrées
• pagination systématique