[🛠] Operations Automation #2: En voulant réunir deux automatisations, j’ai de nouveau séparé les ventes et l’administration du personnel

✨ Résumé de GPT-5.6 Sol

Le récit de ma recherche d’une structure d’automatisation opérationnelle capable de préserver les activités de vente et de messagerie déjà en place, tout en s’étendant à l’inbound et à l’administration du personnel.

J’ai essayé de réunir deux programmes qui fonctionnaient déjà

Au sein de l’entreprise, il existait déjà deux programmes d’automatisation qui avaient évolué dans des directions différentes.

Le premier était un programme de gestion des congés par SMS, initialement développé par mon prédécesseur. Ce service calculait les congés de chaque employé, envoyait des SMS d’incitation à les prendre, puis interprétait les demandes reçues par SMS pour les faire suivre jusqu’à leur approbation ou leur refus. Le Web, le backend, la DB et même le téléphone Android professionnel formaient déjà un seul flux.

Le second était le système de collecte de données publiques et d’automatisation des ventes que je continuais à améliorer. Il recueillait des établissements et leurs coordonnées, les reliait aux appels outbound de Vox, puis les transmettait à l’activité commerciale réelle.

Au début, je pensais qu’il suffirait de déplacer les deux projets dans un même dépôt pour les intégrer. Mais, en réfléchissant aux fonctionnalités que je voulais ajouter, j’ai compris que réunir les dossiers ne suffirait pas.

• la prise en charge inbound reliée à l’outbound existant
• un flux qui reçoit les demandes des employés et les transmet aux tâches administratives
• la génération et la remise automatiques d’attestations d’emploi
• la répartition des droits selon les informations sur les employés, les contrats et les sites d’affectation
• une interface opérationnelle qui regroupe les échecs, les approbations, les retraitements et les journaux d’audit

La question n’était alors plus « comment réunir les deux codes ? », mais « où placer les activités qui vont se multiplier ? ».

J’ai décidé de ne pas jeter le programme existant

En regardant le programme de gestion des congés par SMS, j’avais très envie de repartir de zéro. J’y voyais une ancienne structure, des réglages provisoires et de nombreux éléments que j’aurais aimé reconcevoir selon les standards actuels. Reprendre uniquement les exigences dans un nouveau code semblait pouvoir donner un résultat plus propre.

Mais, à mesure que j’examinais les documents, j’ai découvert dans ce programme des éléments plus importants que le code lui-même.

• les résultats de congés réellement présentés aux employés
• la méthode de calcul des congés à partir de la date d’embauche
• les personnes concernées par les relances et le moment de leur envoi
• les règles d’interprétation des demandes par SMS en dates et demi-journées
• l’ordre entre demande, approbation, refus et SMS de résultat
• la manière dont le téléphone Android professionnel envoyait et recevait les SMS
• les écrans et la gestion des exceptions déjà utilisés par les opérateurs

Si je résumais tout cela en quelques documents avant de repartir de zéro, le nouveau code pourrait être propre tout en produisant des résultats différents pour les utilisateurs existants. Je ne pouvais pas supprimer, par simple préférence de conception, un flux vertical que mon prédécesseur avait réellement achevé.

J’ai donc changé de direction : reproduire d’abord le service existant à l’identique, conserver ses écrans et ses résultats de calcul comme références de régression, puis remplacer ses parties problématiques fonctionnalité par fonctionnalité. Le nouveau système ne devait pas commencer par effacer l’ancien programme. Celui-ci devait rejoindre une structure plus vaste sans perdre ce qu’il savait déjà faire.

Les ventes et l’administration du personnel ne relevaient pas de la même application

Réunir les projets et fusionner en même temps leurs DB et leurs Runtime aurait créé un autre problème.

L’automatisation des ventes traite des données publiques, des coordonnées, des cibles d’appel et des résultats commerciaux. L’administration du personnel traite des informations sur les employés, de l’émission de documents, des congés, des approbations et des messages. Les deux domaines peuvent apparaître ensemble dans une interface opérationnelle, mais la nature des données, les droits et l’étendue des conséquences d’une panne diffèrent.

Je ne voulais pas qu’une migration de la DB des ventes bloque le déploiement de l’administration du personnel, ni qu’une panne du service de congés arrête aussi la collecte commerciale. Les comptes et credentials, les queues, les backups et les rollbacks devaient eux aussi être séparés par activité.

J’ai finalement décidé de conserver un seul dépôt, mais de séparer les ventes et l’administration du personnel en apps indépendantes. L’interface opérationnelle permet de parcourir les deux au même endroit, mais elle ne lit pas directement leurs DB : chaque backend reste responsable de ses propres données et de ses droits.

De l’outbound à l’inbound et aux tâches administratives

L’automatisation commerciale existante ressemblait surtout à un flux outbound, destiné à passer des appels vers l’extérieur. Le 15, j’ai aussi longuement réfléchi à la manière d’y rattacher l’inbound.

Ce n’est pas parce qu’un appel arrive que toutes les demandes doivent être traitées dans le système téléphonique. L’appel peut servir de point d’entrée : il recueille la demande et la transmet au bon processus. Une demande d’attestation d’emploi doit être envoyée vers la vérification d’identité et l’émission du document, puis le document produit doit suivre une procédure de remise distincte. Même si la même demande arrive par le Web ou par mobile, elle doit finalement rejoindre la même tâche administrative.

C’est aussi pour cela que j’ai décidé de commencer par l’attestation d’emploi. Cette première fonctionnalité permettait d’éprouver en une seule fois tout le flux nécessaire à l’automatisation opérationnelle : réception de la demande, vérification des données de référence de l’employé, génération du document, approbation, remise, gestion des échecs et audit.

Il ne suffisait pas de bien construire une seule fonctionnalité. Les mêmes frontières devaient pouvoir être réutilisées pour les prochaines tâches d’administration du personnel.

Il ne fallait pas recréer les données de référence

L’entreprise gérait déjà les employés, les contrats et les affectations sur les sites dans un autre système. L’automatisation avait besoin de ces informations, mais créer de notre côté un deuxième registre maître des employés aurait rapidement entraîné une divergence entre les deux systèmes.

Le système externe devait rester propriétaire des données de référence, tandis que nous ne ferions que lire les informations nécessaires et les conserver sous forme de snapshots validés. Il fallait séparer la fonction qui modifie le registre maître de celle qui utilise ces informations pour traiter des dossiers administratifs.

Le problème était que je n’avais encore confirmé ni le format réel du fichier téléchargé ni l’existence d’un identifiant stable pour les employés. Appeler « matricule » un numéro affiché à l’écran, ou écrire que l’export était en Excel sans même l’avoir vérifié, aurait placé tout le reste de la conception sur de fausses prémisses.

J’ai donc laissé indéterminé ce que j’ignorais.

Les frontières arrêtées ce jour-là

• Le dépôt reste unique, mais les ventes et l’administration du personnel deviennent des apps indépendantes.
• La DB, le Runtime, les credentials, les queues, les backups et les rollbacks sont séparés par activité.
• L’interface opérationnelle intégrée utilise l’API de chaque backend et ne lit pas directement les DB.
• Le service de congés par SMS conserve ses résultats actuels comme références de régression avant un remplacement fonctionnalité par fonctionnalité.
• Le système existant reste propriétaire des données de référence sur les employés, les contrats et les affectations ; l’automatisation ne conserve que des snapshots validés.
• Le premier vertical slice couvre la demande d’attestation d’emploi, sa génération, son approbation, sa remise et la gestion des échecs.

Le 15, je n’ai presque pas écrit de code : j’ai surtout défini ces frontières et l’ordre de migration du service existant.