Comment notre équipe tunisienne a modernisé un système legacy en 90 jours

Trouver un prestataire technique fiable, disponible sur le même fuseau horaire, qui parle français couramment — sans payer les tarifs parisiens. C'est le défi que nous entendons chaque semaine de la part des DSI et dirigeants d'entreprises françaises. La Tunisie répond à ce besoin de façon concrète : même fuseau horaire que la France, français professionnel natif, ingénieurs formés dans des écoles compétitives, à 60-70 % du coût du marché français. Ce cas client illustre ce que cela donne en pratique.

Pourquoi la Tunisie pour le nearshore ?

La Tunisie n'est pas simplement « moins chère que la France ». C'est un pays où plusieurs conditions favorables se cumulent pour rendre le nearshore réellement efficace :

• Fuseau horaire identique : GMT+1 en hiver, GMT+2 en été — aucun décalage avec la France métropolitaine. Les réunions de 9h à 18h se font en temps réel, sans compromis.
• Français professionnel natif : le français est la langue de travail standard dans les entreprises tech tunisiennes. Pas de traduction, pas de malentendu culturel, pas d'intermédiaire.
• Ingénierie de haut niveau : les universités ESPRIT, INSAT et ENSI forment chaque année plusieurs milliers d'ingénieurs sur des cursus rigoureux, comparables aux écoles d'ingénieurs françaises de province.
• Coût 60-70 % inférieur : pour un profil senior équivalent, le coût journalier est nettement inférieur au marché français — sans sacrifier la qualité d'exécution.
• Proximité culturelle : méthodes agiles, itérations courtes, communication directe — la culture de livraison est alignée avec les attentes des clients européens.

Le cas client : un système vieux de 15 ans remplacé en 90 jours

La situation de départ

Le client nous a contactés un mardi après-midi. Son système de gestion des commandes venait de tomber en panne pour la troisième fois de la semaine. Chaque interruption durait entre deux et quatre heures. Chaque heure d'arrêt représentait environ 12 500 € de commandes perdues et de personnel immobilisé. L'entreprise — un fabricant industriel de taille intermédiaire implanté en Europe occidentale — utilisait ce système depuis 15 ans. La société qui l'avait développé avait fermé. Le seul développeur qui connaissait encore le code avait pris sa retraite 18 mois plus tôt.

Premier élément important : toutes les communications avec ce client se sont déroulées en français. Les démonstrations hebdomadaires étaient en français. L'ensemble de la documentation — spécifications fonctionnelles, guide d'administration, supports de formation — a été livré en français. Ce n'était pas une contrainte pour nous ; c'est simplement notre mode de fonctionnement habituel avec les clients francophones.

Ce que nous avons trouvé lors de la semaine d'audit

Avant de nous engager sur un calendrier, nous avons passé une semaine en immersion avec leurs équipes — aux côtés du personnel entrepôt dès la prise de poste du matin, à observer l'équipe commerciale naviguer dans l'interface, et à analyser le schéma de base de données et les journaux serveur.

Le tableau technique était plus préoccupant que le brief initial ne le laissait entendre :

• Un serveur Windows Server 2008 hébergeant une application ASP.NET WebForms sans historique de gestion de version
• Une base de données SQL Server 2008 avec 847 procédures stockées, dont beaucoup non documentées
• Temps de chargement moyen de 5 à 8 minutes pour l'écran principal de saisie des commandes
• Aucun accès mobile — le système nécessitait Internet Explorer 11 sur site
• Plus de 8 heures d'indisponibilité non planifiée par mois sur le trimestre précédent
• Contrat de maintenance annuel à 185 000 €/an avec un prestataire se limitant à maintenir le serveur en vie

Le tableau humain était tout aussi révélateur. L'équipe entrepôt avait développé des contournements : feuilles de secours papier, tableur personnel tenu à jour sur le téléphone d'un responsable, groupe WhatsApp pour annoncer les modifications de commandes. Le système n'était plus seulement lent — il n'était plus fiable aux yeux de ceux qui l'utilisaient.

La décision d'architecture

Deux chemins étaient réalistes : une modernisation incrémentale du code existant, ou une refonte complète sur une stack moderne avec fonctionnement en parallèle jusqu'à la bascule. Nous avons recommandé la refonte. La raison était simple : le code existant n'avait aucun test, aucune documentation, et personne ne maîtrisait l'ensemble des dépendances entre procédures stockées. Travailler dessus de façon incrémentale, c'était opérer à l'aveugle. La refonte parallèle permettait de définir un périmètre clair, de tester sur des cas d'usage réels, et de basculer à une date que nous maîtrisions.

Stack retenu : Vue.js 3 + TypeScript en front, .NET Core 8 en back, SQL Server sur Azure SQL, Azure App Service avec autoscaling. Une équipe de 7 personnes : 4 développeurs, 1 ingénieur DevOps, 1 chef de projet, 1 ingénieur QA automation.

Les 90 jours d'exécution

Semaines 1-2 : Cadrage et architecture. Nous avons cartographié l'ensemble des flux métier en observant les utilisateurs, non en lisant des spécifications — il n'y en avait pas de à jour. Les feuilles papier du responsable entrepôt se sont révélées être la documentation la plus précise du fonctionnement réel des commandes dans l'entreprise. Elles ont servi de base à nos exigences, complétées par deux ateliers formels avec les responsables de département.

Semaines 3-6 : Build principal. Les quatre semaines suivantes ont couvert les flux prioritaires : saisie des commandes, consultation des stocks, processus de préparation et d'expédition. Les démonstrations hebdomadaires avec l'équipe entrepôt ont permis de corriger plusieurs hypothèses erronées. Le système d'origine avait une particularité : les commandes d'un segment client spécifique bénéficiaient d'une priorité de traitement différente — non documentée, mais profondément ancrée dans les habitudes quotidiennes de l'équipe. Sans les démonstrations hebdomadaires, nous l'aurions manquée.

Semaines 7-9 : Migration des données et intégrations. Quinze ans d'historique de commandes, de fiches clients et de catalogue produits — certaines données dans des formats incohérents, d'autres référençant des enregistrements qui n'existaient plus. Nous avons construit les scripts de migration en semaine 7 et les avons exécutés trois fois sur une copie de la base de production avant de valider les résultats. Le système ancien est resté opérationnel pendant cette phase pour permettre aux équipes de croiser les données en cas de doute.

Semaines 10-12 : Fonctionnement en parallèle et bascule. Pendant deux semaines, les deux systèmes ont fonctionné simultanément. Pour une entreprise industrielle où une erreur de traitement de commande peut entraîner un retard de livraison, c'était le bon choix. La bascule a eu lieu un vendredi à 15h — délibérément après la dernière expédition de la semaine. La transition elle-même a duré 45 minutes. L'ancien serveur est resté en standby deux semaines après la bascule et n'a jamais eu à être sollicité.

Les résultats après 90 jours

• Temps de chargement de la saisie commandes : de 5-8 minutes à moins de 2 secondes
• Disponibilité système : de ~95 % à 99,9 % (une seule fenêtre de maintenance planifiée de 23 minutes dans les 90 premiers jours post-lancement)
• Accessibilité mobile : de 0 % à 100 % — n'importe quel appareil, n'importe quel navigateur
• Tickets support liés au système : baisse de 62 % le premier mois
• Coût annuel d'infrastructure et de maintenance : de 185 000 €/an à 38 000 €/an
• Économies quantifiées la première année : 247 000 €, pour un coût de refonte de 148 000 €

Le responsable entrepôt a rangé ses feuilles de secours papier dès la troisième semaine du nouveau système. C'est l'indicateur le plus honnête de succès que nous ayons eu.

Ce qui rend une équipe tunisienne différente

1. Bilinguisme natif français/anglais. Aucune barrière de communication, aucun surcoût de traduction, aucun malentendu dans les spécifications. Quand votre chef de projet tunisien anime une démonstration en français devant votre comité de direction, le débat porte sur le fond — pas sur la forme.

2. Fuseau horaire aligné. Les réunions se tiennent entre 9h et 18h sans décalage. Quand un problème surgit en production un mardi matin, l'équipe est disponible immédiatement — pas en fin d'après-midi comme avec une équipe en Asie du Sud-Est, ni la nuit comme avec une équipe américaine.

3. Formation d'ingénierie rigoureuse et culture de livraison agile. Les ingénieurs issus d'ESPRIT, d'INSAT ou d'ENSI ont suivi des cursus exigeants, avec des examens d'entrée sélectifs et des projets pratiques. Associée à une culture de livraison itérative — démonstrations hebdomadaires, discipline du périmètre, CI/CD dès le premier jour — cette formation produit des équipes qui livrent, pas seulement des équipes qui codent.

Ce que ce projet nous a appris

Ce projet ne s'est pas déroulé sans complexité, et nous préférons l'honnêteté à la communication marketing.

Le problème de calcul des frais de port. En semaine 8, nous avons découvert que le système d'origine calculait les frais de port selon un barème qui n'avait pas été mis à jour depuis 2019. Le nouveau système utilisait les tarifs actuels. Ce n'était pas un bug — c'était un point de décision. Nous l'avons signalé immédiatement au client. La décision est revenue en 24 heures, la configuration a été mise à jour. L'identifier avant le démarrage plutôt qu'après nous a évité un mois de confusion sur les factures.

La documentation API de Sage. L'intégration avec le logiciel de comptabilité (Sage) a été la partie la plus chronophage du projet — principalement parce que la documentation officielle de l'API était incomplète. Nous avons dû tester contre une instance en production pour comprendre le comportement réel. Nous avions intégré une semaine tampon pour ce type d'aléa. C'est exactement ce qu'il nous a fallu. La leçon : sur ce genre de projet, les intégrations tierces sont toujours plus complexes que prévu. La budgéter, c'est la gérer.

Vous avez un projet similaire ?

Si votre entreprise fait tourner un logiciel qui tombe régulièrement en panne, qui est devenu un frein à votre activité, ou dont la maintenance absorbe un budget disproportionné — la question n'est généralement pas de savoir s'il faut moderniser, mais quand et comment.

Une refonte correctement cadrée, avec les bons choix technologiques et une discipline rigoureuse sur le périmètre, est réalisable en 90 jours. Pas toujours. Mais plus souvent que la plupart des entreprises ne l'imaginent.

Vous avez un projet de modernisation ou de développement sur mesure ? Parlons-en en français.