Ordonnanceur informatique : les règles d'un expert OpCon.

Chaque nuit, des milliers de traitements font vivre votre système d'information en coulisses : paiements, réassorts, consolidations comptables, envois de fichiers aux partenaires.

01Qu'est-ce qu'un ordonnanceur informatique ?

Un ordonnanceur est un outil qui lance des tâches génériques de type batch, appelées jobs, et qui les enchaîne sans intervention humaine. Le principe tient en une ligne. Sa mise en œuvre, elle, occupe des carrières entières.

Un job, trois déclencheurs

Le démarrage d'un job peut s'appuyer sur trois familles de conditions, utilisées seules ou combinées selon le besoin :

Dans OpCon, ces trois dimensions portent un nom précis. Les fréquences décrivent les règles calendaires qui rendent un job éligible. Les dépendances relient les jobs entre eux, au sein d'un même schedule ou d'un schedule à l'autre, avec des types comme After, Requires ou Conflict. Les thresholds, des variables numériques stockées en base, et les resources, des compteurs de jetons, pilotent l'exécution et limitent la concurrence.

Code retour, automatisation, verbosité

L'objectif est double : réduire au minimum les interventions humaines et garantir l'enchaînement. Trois mécanismes le rendent possible. Le code retour indique à l'ordonnanceur si le traitement a réussi. L'automatisation déclenche la suite sans attendre le clic d'un opérateur. La verbosité, portée par les logs, permet de reconstituer après coup ce qui s'est passé.

Les bénéfices se lisent sur trois plans : moins de risques liés aux manipulations manuelles, des exploitants qui passent du rôle de presse-bouton à celui de pilote, et la capacité à faire dialoguer des technologies et des métiers qui s'ignoraient. La règle économique reste simple. La valeur produite doit dépasser la somme des coûts humains et des coûts logiciels ; quand l'équation s'inverse, la chaîne mérite d'être revue.

Valeur>coûts humains+coûts logiciels

02Scheduler, WLA, SOAP : situer l'ordonnanceur parmi les outils d'automatisation

Le mot automatisation recouvre des réalités très variées. Côté matériel, il désigne la robotique, les usines ou l'électronique embarquée. Côté logiciel, qui concerne cet article, les outils se répartissent en quatre catégories : front-end, back-end, data et intégrations.

Front-end : imiter ou modéliser l'utilisateur

Le RPA (Robotic Process Automation) reproduit les gestes d'un utilisateur, comme un clic ou la récupération d'une pièce jointe, sur des applications dépourvues d'interface de programmation. Le BPA (Business Process Automation) automatise des processus métier transverses, souvent en no-code. L'IPA (Intelligent Process Automation) ajoute au RPA des décisions dynamiques fondées sur l'analyse de données et le machine learning. Power Automate, Webcon et les offres d'IBM illustrent respectivement ces trois familles.

Back-end : du planificateur à l'orchestration

L'ordonnanceur vit ici, sous plusieurs formes :

Gartner a popularisé le terme SOAP pour désigner l'évolution des outils de workload automation vers le cloud et l'orchestration de bout en bout. Dans les faits, les frontières restent poreuses. OpCon, historiquement rangé dans le WLA, couvre aujourd'hui une large part du périmètre SOAP grâce à son API REST, à son offre SaaS hébergée sur Azure et à ses modules de déploiement.

Data et intégrations

Deux familles complètent le paysage. Les ETL (Extract, Transform, Load) comme Talend rassemblent puis transforment les données. Côté intégrations, les iPaaS comme Axway connectent applications et bases dans le cloud, et l'API management, avec SwaggerHub par exemple, encadre l'exposition des API. En production, ces outils tournent très souvent sous le contrôle d'un ordonnanceur. Un job Talend reste un job.

03Un ordonnanceur bien utilisé : huit règles de conception

Comme tout outil, un ordonnanceur vaut par l'usage qu'on en fait. Le principe fondateur tient en une phrase : l'intelligence métier se loge dans le script exécuté, et l'ordonnanceur se concentre sur ce qu'il fait le mieux, à savoir lancer, enchaîner, surveiller et alerter. Un plan de production truffé de conditions métier codées dans l'outil devient illisible en quelques mois.

L'intelligence métier se loge dans le script exécuté.

Voici les règles d'implémentation recommandées, avec leur traduction dans OpCon :

1. Une entité logique de traitement correspond à un job.

   Un job qui extrait, transforme, envoie et purge d'un seul tenant ne peut pas reprendre à l'étape en échec.

2. Un traitement dure au maximum une vingtaine de minutes.

   Au delà, on découpe. La reprise devient plus fine et les dérives de durée sautent aux yeux.

3. Le code retour est obligatoire.

   OpCon détermine le statut final à partir de critères d'échec sur l'exit code (égal, différent, inférieur, supérieur). Un script qui sort toujours en 0 rend l'outil aveugle.

4. Les logs sont lisibles dans les sorties standards.

   L'agent OpCon, le LSAM, remonte la sortie du job : l'exploitant lit le diagnostic depuis la console, sans se connecter au serveur.

5. Un job se relance sans altérer les données.

   C'est l'idempotence : rejouer le traitement produit le même état final qu'une exécution unique réussie.

6. Un job peut être arrêté d'urgence.

   Le script intercepte le signal d'arrêt envoyé depuis la console et nettoie derrière lui.

7. Une gestion d'alerte est en place.

   Les événements OpCon déclenchés sur changement de statut alimentent une notification, un ticket ou la mise à jour d'un threshold.

8. La documentation est obligatoire.

   OpCon propose une documentation intégrée à la définition du job, et l'exploitant d'astreinte de 3 h du matin doit y trouver quoi faire.

À quoi ressemble un script conforme

Voici un squelette Shell qui respecte ces règles. La fonction extraire_ventes représente la commande métier.

#!/usr/bin/env bash
# SHL_FAC_EXPORT_VENTES : export quotidien des ventes vers l'entrepôt de données
set -euo pipefail

JOB="SHL_FAC_EXPORT_VENTES"
JOUR="${1:?Date de traitement attendue au format AAAAMMJJ}"
CIBLE="/data/export/ventes_${JOUR}.csv"
TEMP="${CIBLE}.tmp"

log() { echo "$(date '+%F %T') [${JOB}] $*"; }

nettoyage() {
  rm -f "${TEMP}"
  log "Arrêt demandé, fichier temporaire supprimé"
  exit 143
}
trap nettoyage TERM INT

log "Début du traitement pour le ${JOUR}"

# Relance sans effet de bord : le fichier complet est toujours reconstruit
rm -f "${TEMP}"
if ! extraire_ventes "${JOUR}" > "${TEMP}"; then
  log "ERREUR extraction en échec"
  exit 20
fi

NB=$(wc -l < "${TEMP}")
if [ "${NB}" -le 1 ]; then
  log "ERREUR fichier vide, aucune vente remontée pour le ${JOUR}"
  exit 30
fi

mv -f "${TEMP}" "${CIBLE}"
log "Fin OK : ${NB} lignes écrites dans ${CIBLE}"
exit 0

Trois détails comptent. Le fichier final n'apparaît qu'une fois complet, grâce au passage par un fichier temporaire, ce qui rend la relance sans risque. Les codes 20 et 30 distinguent deux causes d'échec, et OpCon peut réagir différemment à chacune, par exemple en relançant automatiquement la première et en alertant le métier pour la seconde. Enfin, le trap garantit qu'un arrêt demandé depuis la console laisse un système propre.

Un mot sur le Job Output Parsing d'OpCon, qui convertit une chaîne trouvée dans la sortie en code retour. Il dépanne face à un exécutable tiers qui renvoie 0 en toutes circonstances. Sur des scripts développés en interne, son usage révèle généralement une dette technique.

04Exemple concret : ce qui se passe quand vous achetez un vélo

Prenons le cas d'une enseigne d'articles de sport. Un client passe en caisse avec un vélo pour enfant. Derrière ce geste anodin, une cascade d'échanges traverse la banque, la logistique, la finance et le pilotage commercial :

Passage en caisse

• l'autorisation de paiement part vers la banque, à la demande et en temps réel ;
• le stock du magasin se met à jour, puis alimente le réassort de l'entrepôt selon un cycle régulier ;
• la préparation et la livraison des commandes s'appuient sur ces mêmes données ;
• pendant la nuit, les ventes sont consolidées pour le reporting du lendemain matin.

Certains flux partent à la demande, d'autres sont périodiques. L'ordonnanceur planifie les seconds et réagit aux premiers.

Tout se complique avec les exceptions. Que faire si les caisses perdent le réseau, si l'entrepôt est inondé ou si les chiffres de vente ne sont toujours pas à jour à 8 h ? Chaque cas connu reçoit un scénario préparé à l'avance : mode dégradé avec remontée différée des tickets, bascule du réassort vers un autre site, dépendance qui bloque le reporting et prévient l'équipe avant l'ouverture des bureaux. Reste le cas inconnu. Pour lui, la seule réponse saine consiste à s'arrêter proprement, à renvoyer un code retour explicite et à prévenir un humain.

À quoi ça ressemble dans un plan de production

Prenons l'exemple d'un job cyclique. Il s'exécute du lundi au vendredi, jours ouvrés uniquement, à partir de 7 h, puis toutes les 15 minutes sans interruption. À chaque cycle :

1. le job démarre et produit un code retour ;
2. si le code est bon, le traitement est marqué OK ;
3. dans le cas contraire, une alerte part vers l'équipe concernée ;
4. dans les deux cas, le job attend la fin de la fenêtre de 15 minutes avant de repartir.

Ce schéma convient bien à l'intégration de fichiers qui arrivent au fil de l'eau : un échec ponctuel laisse au cycle suivant la possibilité de rattraper le retard, à condition que le job soit idempotent. Pour un traitement dont l'échec rend la suite dangereuse, il est préférable de bloquer le cycle jusqu'à l'intervention d'un exploitant. Ce choix se tranche avec le métier.

05Les métiers de la production IT autour de l'ordonnanceur

Industrie, restauration, éducation, énergie : selon le secteur, l'ordonnanceur s'aborde de façon différente. Pour rendre service, il faut penser métier. Une fenêtre batch de fin de journée bancaire, un pic de réassort avant les fêtes et un calcul de consommation énergétique imposent des contraintes sans rapport entre elles, et le contexte dicte directement les méthodes d'implémentation. La finalité reste constante : dégager un bénéfice financier et donner plus de valeur au travail humain.

Autour de l'ordonnancement, les équipes de production s'organisent en plusieurs activités outillées :

L'ordonnanceur sert de point de jonction entre ces activités. Un job en échec ouvre un incident dans l'ITSM, un transfert de fichier conditionne le démarrage d'une chaîne, la supervision contrôle le respect des SLA. OpCon intègre d'ailleurs une partie de ces briques dans ses propres modules, comme OpCon MFT pour les transferts ou OpCon Vision pour le suivi des SLA, présentés sur la page consacrée à la plateforme d'automatisation OpCon.

06Les défis de l'expert en ordonnancement

Normaliser et vulgariser

Une norme a de la valeur quand les équipes la comprennent et l'appliquent. Sensibiliser, vulgariser, accompagner : ce travail pédagogique prend autant de temps que la technique. Parler le même langage aide beaucoup, et une convention de nommage fondée sur un trigramme de technologie en donne un bon exemple :

Associé à un code application et à une fonction, le trigramme produit un nom de job qui se lit sans documentation. SHL_FAC_EXPORT_VENTES annonce un script Shell de l'application de facturation qui exporte les ventes, et l'exploitant d'astreinte sait immédiatement où chercher. Un plan de production que seul son auteur sait lire constitue une dette, au même titre qu'un code sans tests.

Rendre la valeur visible

Un ordonnancement bien conçu passe inaperçu. C'est tout le paradoxe du métier : quand rien ne casse, personne ne pense à l'ordonnanceur. Pour valoriser les actions menées, une frise chronologique appuyée sur des indicateurs change la discussion : volumétrie de jobs, occurrences, incidents par mois, avant et après chaque chantier. Une courbe d'incidents qui baisse, placée en regard d'une refonte de chaîne, convainc une direction bien mieux qu'un long exposé technique.

07Quelques ordonnanceurs du marché

Le marché réunit des planificateurs natifs et des plateformes d'entreprise, chacune avec son histoire :

OpCon se distingue par plusieurs atouts concrets. Les agents couvrent un large éventail de systèmes, du Windows au Unix en passant par l'IBM i. Le mécanisme de Master permet de dédupliquer les définitions de workflows, ce qui allège fortement la maintenance. Le Self Service laisse un utilisateur métier déclencher un workflow d'un clic, sans ticket. OpCon Deploy, enfin, gère la promotion des workflows entre environnements. Le meilleur outil reste toutefois celui qui colle à votre existant, et changer d'ordonnanceur se prépare comme un projet de reprise de données à part entière.

MS

Article rédigé parMohamed SouissiIngénieur de Production chez Ntico