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.

Deux programmes 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 n’étaient pas le même app

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.

Même si l’extérieur présente une seule interface opérationnelle intégrée, l’intérieur n’a pas besoin de devenir un service monolithique gigantesque.

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. Cette journée a produit de nombreuses réponses, mais j’ai aussi réécrit sans cesse mes phrases pour ne pas faire semblant de savoir ce que je ne savais pas encore.

Intégrer ne consistait pas à réunir des dossiers

Le 15, je n’ai presque pas écrit de code. J’ai surtout continué à clarifier le nom du projet, les frontières entre les apps, la propriété des données, l’ordre de migration du service existant et le rôle de l’interface opérationnelle.

Je voulais respecter le programme créé par mon prédécesseur sans pour autant le figer, et ne pas enfermer non plus l’automatisation des ventes que j’avais construite dans sa structure actuelle. Elle devait pouvoir s’étendre de l’outbound Vox existant à l’inbound, puis à l’administration du personnel et à l’automatisation documentaire.

Placer les deux projets dans le même dossier était facile. Le plus difficile était de décider quoi préserver, quoi séparer et par où commencer l’extension. Le 15 est le jour où j’ai commencé à regarder deux automatisations différentes comme une seule structure opérationnelle.