Migration RoboTask vers Python : Comment j'ai Libéré une Automatisation Critique

Quand un client m'a contacté pour un problème d'automatisation critique, je ne m'attendais pas à plonger dans les entrailles d'un système RoboTask vieux de plusieurs années. Leur défi ? Migrer une automatisation complexe sans casser le flux de production, tout en se libérant d'une dépendance logicielle coûteuse.

Voici le retour d'expérience complet de cette migration : de l'analyse des règles métier obscures à la validation finale avec 100% de conformité.

Le Problème : Une Dépendance Coûteuse

La Situation de Départ

L'entreprise utilisait RoboTask, un logiciel d'automatisation Windows payant, pour orchestrer un processus critique qui s'exécutait chaque nuit :

• 📥 Téléchargement FTP de fichiers CSV depuis un serveur distant
• 📊 Import automatique dans Cegid Manufacturing PMI (leur ERP)
• 🔄 Transformation complexe selon des règles métier spécifiques
• 🏢 Gestion multi-sociétés avec identifiants différents

Le processus tournait depuis des années sans problème... mais avec trois inconvénients majeurs :

Les Objectifs de la Migration

Le cahier des charges était clair :

• ✅ Solution gratuite et open source
• ✅ Comportement identique à RoboTask (validation à 100%)
• ✅ Logs détaillés pour le débogage
• ✅ Maintenabilité améliorée (code versionnable)
• ✅ Flexibilité pour futures évolutions

Le piège ? Impossible de tester en production. Le processus impactait directement l'ERP, et une erreur pouvait avoir des conséquences financières. Il fallait donc une validation parfaite avant le basculement.

L'Architecture Python : Simple mais Robuste

J'ai conçu une solution modulaire en Python, avec trois scripts principaux qui reproduisent exactement le comportement de RoboTask :

Composant 1 : Téléchargement FTP Multi-Sociétés

Technologies utilisées :

Composant 2 : Import et Transformation Cegid PMI

C'est ici que se trouvait la vraie complexité : les fichiers CSV contenaient des données à transformer selon des règles métier obscures avant injection dans l'ERP.

Technologies utilisées :

Composant 3 : Orchestration et Planification

Un script orchestrateur lance les deux composants dans l'ordre, gère les erreurs, et génère un rapport complet. Le tout planifié via le Planificateur de tâches Windows avec système de réessais (4h, 5h, 6h, 7h, 8h) si les fichiers ne sont pas encore disponibles.

Les Défis Techniques (Et Comment Je Les Ai Résolus)

Défi #1 : Décoder les Règles Métier

Le plus gros challenge n'était pas technique, mais analytique. RoboTask exécutait des transformations complexes sans documentation claire.

J'ai analysé 321 requêtes SQL générées par RoboTask sur des données réelles, puis recréé la logique exacte en Python. Validation finale : 100% de conformité.

Défi #2 : L'Erreur du Planificateur Windows

Solution : Création de wrappers batch intelligents qui trouvent Python automatiquement.

@echo off
:: Trouver Python automatiquement
where python >nul 2>&1
if %ERRORLEVEL% EQU 0 (
    python "C:\Scripts\assurance\workflow_assurance_complet.py"
) else (
    "C:\Program Files\Python312\python.exe" "C:\Scripts\assurance\workflow_assurance_complet.py"
)

Résultat : déploiement robuste sur n'importe quelle machine Windows, même sans Python dans le PATH système.

Défi #3 : Gestion des Encodages

Les fichiers CSV étaient en ISO-8859-1 (Latin-1), pas en UTF-8. Et Windows ajoute sa propre couche de complexité avec l'encodage cp1252 dans les subprocess.

Solution :

# Lecture CSV
with open(filepath, 'r', encoding='iso-8859-1') as f:
    reader = csv.DictReader(f, delimiter=';')
    
# Subprocess Windows
subprocess.run(..., 
    encoding='cp1252',
    errors='replace')

Bonus : Sécurisation de l'Accès SQL Server

Pendant le développement, j'ai identifié un problème de sécurité critique : RoboTask utilisait le compte sa (System Administrator) pour se connecter à SQL Server. C'est une **très mauvaise pratique**.

Le Problème avec `sa`

Utiliser sa dans un script automatisé signifie que si le script est compromis, **toute l'instance SQL Server** est vulnérable. C'est comme donner les clés du coffre-fort à quelqu'un qui a juste besoin d'accéder à un tiroir.

La Solution : Utilisateur Dédié avec Permissions Minimales

J'ai créé un utilisateur SQL dédié assurance_import avec uniquement les permissions nécessaires :

Création de l'Utilisateur SQL

-- Créer le login SQL Server
USE master;
GO

CREATE LOGIN assurance_import 
WITH PASSWORD = 'MotDeP@sse!Fort#2025',
     DEFAULT_DATABASE = PMI,
     CHECK_POLICY = ON,
     CHECK_EXPIRATION = OFF;
GO

-- Créer l'utilisateur dans la base
USE PMI;
GO

CREATE USER assurance_import FOR LOGIN assurance_import;
GO

-- Accorder uniquement les permissions nécessaires
GRANT SELECT ON dbo.CLIENT TO assurance_import;
GRANT UPDATE ON dbo.CLIENT TO assurance_import;
GRANT CONNECT TO assurance_import;
GO

Intégration Python Sécurisée

Avant (❌ Mauvaise pratique) :

# Utilisation du compte admin
DB_USER = "sa"
DB_PASSWORD = "motdepasse_admin"

Après (✅ Bonne pratique) :

# Utilisateur dédié avec permissions minimales
DB_USER = "assurance_import"
DB_PASSWORD = "MotDeP@sse!Fort#2025"

# Connexion via pyodbc
conn = pyodbc.connect(
    "DRIVER={SQL Server};"
    "SERVER=mon-serveur;"
    "DATABASE=PMI;"
    f"UID={DB_USER};"
    f"PWD={DB_PASSWORD};"
)

Protection du Mot de Passe

Le mot de passe SQL ne doit jamais être en dur dans le code. J'ai utilisé un fichier de configuration séparé avec permissions Windows restrictives :

# config.ini (protégé par permissions Windows)
[DATABASE]
server = mon-serveur
database = PMI
username = assurance_import
password = MotDeP@sse!Fort#2025

Sécurisation avec PowerShell :

# Supprimer l'héritage et autoriser uniquement le compte courant
icacls.exe .\config.ini /inheritance:r
icacls.exe .\config.ini /grant:r "${env:USERNAME}:(R,W)"

# Résultat : Seul votre compte Windows peut lire ce fichier

Validation des Permissions

J'ai testé pour m'assurer que les permissions fonctionnaient correctement :

# ✅ Doit fonctionner : UPDATE
UPDATE CLIENT SET CLCTLIBRE4 = 'Test' 
WHERE CLKTSOC = '100' AND CLKTCODE = '123456';
-- Succès : Permission accordée

# ❌ Doit échouer : INSERT
INSERT INTO CLIENT (CLKTSOC, CLKTCODE) VALUES ('100', '999999');
-- Erreur : The INSERT permission was denied

# ❌ Doit échouer : DELETE
DELETE FROM CLIENT WHERE CLKTCODE = '123456';
-- Erreur : The DELETE permission was denied

Résultats : Mission Accomplie

Comparaison RoboTask vs Python

Métriques du Projet

Bénéfices Concrets

Économies :

• 💰 ~200€/an de licence RoboTask économisés
• ⏱️ -50% de temps de maintenance (logs clairs, code versionné)
• 🚀 Évolutivité : Ajout de nouvelles sociétés en 5 minutes

Flexibilité :

• 📧 Notifications email facilement ajoutables
• 📊 Dashboard de monitoring possible
• 🔄 API REST pour déclenchement à la demande
• ☁️ Migration cloud envisageable

Leçons Apprises

1. Analyser avec des Données Réelles

Ne vous fiez jamais uniquement à la documentation. J'ai passé plusieurs heures à analyser les fichiers CSV réels et les requêtes SQL générées par RoboTask. C'est ce qui m'a permis de découvrir des règles métier non documentées.

2. Validation à 100% Avant Bascule

Quand on touche à un système de production critique, il n'y a pas de place pour "ça devrait marcher". J'ai comparé 321 requêtes SQL générées par les deux systèmes, ligne par ligne. Résultat : conformité parfaite.

3. Gérer les Particularités Windows

Windows a ses propres spécificités : encodages (cp1252), PATH système vs utilisateur, Planificateur de tâches. Les wrappers batch ont été la solution pour un déploiement robuste.

4. Logs Détaillés = Gain de Temps

Investir du temps dans un système de logs structurés (horodatés, séparés par société, avec niveaux de gravité) est toujours rentable. Le débogage en production devient trivial.

5. Sécurité d'Abord : Ne Jamais Utiliser `sa`

La création d'un utilisateur SQL dédié avec permissions minimales n'est pas optionnelle, c'est une exigence de sécurité. Même si "ça fonctionne" avec sa, le risque en cas de compromission est inacceptable. 15 minutes d'investissement pour une sécurité renforcée à vie ? C'est un no-brainer.

Conclusion

Cette migration montre qu'il est tout à fait possible de se libérer de dépendances logicielles coûteuses tout en conservant (voire améliorant) la qualité du service.

Les clés du succès ? Une analyse minutieuse de l'existant, une validation rigoureuse avec données réelles, et une architecture modulaire et maintenable.

Le client a non seulement économisé 200€/an, mais a aussi gagné en flexibilité, en traçabilité, et en capacité d'évolution. Le code est versionné sur Git, documenté, et prêt pour de futures améliorations (notifications, dashboard, API...).

ROI : Immédiat. Satisfaction client : 100%. Complexité technique : Maîtrisée. Mission accomplie. ✅