Algeria AgencyWeb & logiciel
Remplacer un système qui marche encore
Quatre raisons justifient de remplacer un logiciel ancien. En dehors de ces quatre, le garder est presque toujours la bonne décision — et personne n’a intérêt à vous le dire.
Il existe une conversation que presque personne n’a intérêt à mener honnêtement avec vous, et c’est celle-ci : faut-il remplacer le logiciel que vous utilisez depuis douze ans ? L’éditeur du nouveau est payé si vous dites oui. L’intégrateur est payé si vous dites oui. Nous sommes payés si vous dites oui.
Alors commençons par la réponse qui nous coûte de l’argent. Dans la moitié environ des demandes qui nous arrivent sur ce sujet, le bon conseil est de ne rien faire. Un logiciel ancien qui fait le travail, dont quelqu’un sait se servir et dont les données sortent, n’est pas un problème d’entreprise. C’est un actif amorti.
Cet article donne les quatre conditions qui, elles, justifient réellement le remplacement, et il les donne assez précisément pour que vous puissiez les vérifier vous-même, sans nous. Trois d’entre elles se constatent en une après-midi. La quatrième demande un test que peu d’entreprises ont fait.
Il décrit ensuite ce que la migration rencontre réellement quand elle est justifiée — l’encodage, le papier, les règles que personne n’a écrites, la personne qui part — parce que c’est là que les projets échouent, et jamais dans le développement du nouveau logiciel.
« Vieux » n’est pas un diagnostic
L’âge d’un logiciel ne dit rien sur sa valeur. Une application écrite en 2009 qui édite vos factures correctement édite vos factures correctement, et le fait qu’elle ait l’air de 2009 ne coûte rien à personne — sauf à celui qui la regarde en espérant vendre son remplacement.
Le mot qui remplace l’argument, dans presque tous les devis que nos clients nous montrent, est « obsolète ». C’est un mot vide. Il ne désigne aucune propriété vérifiable du système : il désigne l’impression qu’il produit. Demandez ce qu’il signifie précisément et la conversation devient tout de suite plus utile.
Quatre conditions, elles, sont vérifiables, et ce sont les seules qui justifient la dépense. Le logiciel ne reçoit plus de correctifs de sécurité. Une seule personne sait le faire fonctionner. Il vous empêche de faire une chose que vous devez faire maintenant. Ou ses données ne sortent pas.
Ces quatre-là ne sont pas des opinions. Chacune se constate, et trois se constatent sans aide extérieure. Si aucune ne s’applique chez vous, la bonne décision est de garder le système et de mettre l’argent sur quelque chose qui manque vraiment.
Le reste de cet article suppose qu’au moins une s’applique. Si ce n’est pas votre cas, vous pouvez vous arrêter ici, et c’est un résultat : vous venez d’économiser un budget que quelqu’un s’apprêtait à vous faire dépenser.
Le système central de beaucoup d’entreprises est un fichier Excel
Quand on parle de « système existant », l’image qui vient est celle d’un vieux logiciel installé sur un serveur. Dans les entreprises que nous voyons, la réalité est plus souvent un classeur.
Il a commencé comme une commodité — un tableau pour suivre les commandes, en attendant. Puis quelqu’un a ajouté un onglet, puis une formule, puis une couleur qui veut dire quelque chose que seule une personne connaît. Aujourd’hui il fait tourner l’entreprise, il vit sur un poste, et il porte le nom de quelqu’un dans son titre.
Nous ne savons pas quelle proportion des entreprises algériennes est dans ce cas, et nous n’allons pas l’inventer : personne ne publie ce chiffre, ni l’ONS ni aucune enquête sectorielle que nous ayons pu vérifier. Ce que nous pouvons dire est ce que nous constatons chez nos propres clients, et ce n’est pas une statistique.
Ce qui compte, en revanche, est que ce classeur remplit exactement les quatre conditions plus souvent qu’un vrai logiciel. Une seule personne sait comment il marche. Il n’a jamais reçu le moindre correctif. Il empêche à peu près tout — travail simultané, historique, contrôle des saisies. Et ses données sortent mal, parce qu’un tableau n’a pas de structure imposée.
Un classeur devenu critique est donc un système existant à part entière, et il se traite avec les mêmes précautions qu’un logiciel : audit de sortie, reprise d’historique, fonctionnement en parallèle. Le traiter comme « juste un Excel » est la façon la plus courante de perdre dix ans de données.
La seule des quatre conditions qui porte une date
Des quatre conditions, une seule s’accompagne d’un calendrier public : la fin des correctifs de sécurité. Les autres se dégradent lentement ; celle-ci a une date, elle est écrite par l’éditeur, et elle ne se négocie pas.
La politique de cycle de vie de Microsoft est l’exemple le plus utile, parce que la plupart des logiciels métier anciens tournent sur un Windows Server, et que la date de fin du serveur devient de fait la date de fin du logiciel qu’il porte.
Le graphique ci-contre donne, pour les trois éditions encore en service, le nombre de mois de correctifs restants. L’édition 2016 est à cinq mois. Ce n’est pas un avertissement lointain : c’est un trimestre et demi, et un projet de migration sérieux en demande davantage.
Ce que « fin des correctifs » signifie mérite d’être dit précisément, parce que le terme rassure à tort. Le serveur ne s’arrête pas. Il continue de fonctionner exactement comme la veille. Ce qui change est qu’à partir de cette date, chaque faille découverte reste ouverte pour toujours, et que ces failles sont publiées.
C’est la seule des quatre conditions qui impose son propre calendrier au vôtre. Les trois autres vous laissent choisir le moment ; celle-ci le choisit pour vous, et l’ignorer transforme un projet planifié en réaction d’urgence, qui coûte davantage et se fait moins bien.
Microsoft, politique de cycle de vie fixe, consultée en 2026
La personne qui sait, et ce qui part avec elle
Dans beaucoup d’entreprises, le système ne tient pas sur une documentation mais sur un employé. Il sait dans quel ordre lancer les choses, ce qu’il faut faire quand l’écran affiche cette erreur-là, et pourquoi il ne faut jamais saisir une commande le dernier jour du mois.
Ce savoir n’est écrit nulle part, et il n’est pas paresseux de ne pas l’avoir écrit : personne ne sait qu’il le possède. Il se révèle le jour où la personne est absente, et il se mesure à ce moment-là seulement, en heures d’arrêt.
Le risque est réel mais il est mal traité, parce qu’on le traite comme un risque informatique alors que c’est un risque de personne. Remplacer le logiciel ne le supprime pas automatiquement : un nouveau système peut très bien reconstituer la même dépendance en dix-huit mois si personne n’écrit rien.
Ce qui supprime le risque est l’écriture, et le remplacement n’en est que l’occasion. Une migration bien menée passe une part importante de son temps à suivre cette personne, à lui demander pourquoi elle fait ce qu’elle fait, et à transformer ses réponses en règles explicites.
C’est aussi pourquoi une migration ne peut pas se faire pendant que les gens travaillent normalement. Si vous ne pouvez pas libérer la personne qui sait, la migration produira un système qui fait ce que le cahier des charges décrivait, et non ce que l’entreprise fait.
Les données avant le code : le seul test qui compte
La quatrième condition est celle que presque personne ne vérifie avant de signer, et c’est la seule qui peut arrêter le projet net. Vos données sortent-elles ?
La question n’est pas « le logiciel a-t-il une fonction export ». Beaucoup en ont une, et elle exporte l’écran affiché, pas la base. Ce qui compte est de sortir la totalité : les clients, les articles, l’historique complet des mouvements, avec les liens entre eux, dans un format qu’un autre programme peut relire.
Le test se fait avant tout devis, et il se fait en vrai. Nous demandons systématiquement une extraction complète sur les données réelles au tout début, parce que son résultat change la nature du projet. Une base lisible donne une migration ordinaire. Une base fermée donne un projet trois fois plus long, ou pas de projet du tout.
C’est aussi le test qui révèle les mauvaises surprises tôt, quand elles ne coûtent encore rien : des champs remplis n’importe comment parce qu’ils ne servaient plus, des doublons que le logiciel masquait, des dates au format américain sur trois années précises. Toutes ces choses se réparent avant de migrer, et beaucoup plus difficilement après.
Un prestataire qui vous donne un prix ferme pour une migration sans avoir vu vos données ne vous a pas donné un prix. Il vous a donné une hypothèse, et vous en porterez seul le dépassement.
L’arabe et le français dans le même fichier
Vient maintenant la difficulté que les articles étrangers sur ce sujet ne mentionnent jamais, et qui est chez nous la première cause de reprise ratée.
Une part des données saisies dans les logiciels installés ici dans les années 2000 et 2010 l’a été en arabe, sur des systèmes conçus quand le codage universel des caractères n’était pas encore la norme. Une autre part a été saisie en arabe translittéré en caractères latins, par un opérateur pressé ou par un formulaire qui n’acceptait pas autre chose. Une troisième est en français.
À l’extraction, cela ne produit pas une erreur franche, ce qui serait préférable. Cela produit un mélange : une partie des noms ressort correctement, une autre ressort en suites de caractères illisibles, et rien ne signale la différence. Le fichier a l’air bon quand on l’ouvre et regarde les vingt premières lignes.
Nous ne pouvons pas vous dire quelle proportion d’un fichier client algérien type est concernée, parce que ce chiffre n’existe pas — il dépend du logiciel d’origine, de l’année d’installation et des habitudes de saisie de chaque entreprise. Ce que nous pouvons dire est qu’il n’est jamais nul, et qu’il faut le mesurer sur vos données plutôt que le supposer.
La réparation est un travail à part entière : identifier les encodages présents, les convertir, et faire relire un échantillon par quelqu’un qui lit l’arabe et connaît vos clients. Ce dernier point n’est pas automatisable, et un devis de migration qui ne prévoit pas ces heures-là prévoit de les découvrir en cours de route.
Ce que le logiciel fait n’est pas ce que l’entreprise fait
Il existe toujours un écart entre la procédure telle qu’elle est décrite et la procédure telle qu’elle est appliquée, et cet écart est le contenu réel du projet.
Les exemples se ressemblent d’une entreprise à l’autre. Ce client-là paie à soixante jours mais on le saisit à trente parce que sinon le logiciel bloque la commande. Cette remise-là ne se saisit pas, on l’applique à la main sur la facture. Ce champ « référence interne » sert en réalité à noter le nom du commercial, depuis 2017.
Aucune de ces règles n’est écrite. Toutes sont indispensables. Et aucune n’apparaîtra dans un cahier des charges rédigé en salle de réunion, parce que les gens qui les appliquent ne les vivent pas comme des règles : ils les vivent comme la manière normale de travailler.
La seule façon de les récupérer est de regarder les gens travailler, plusieurs jours, en posant des questions sur ce qui semble anodin. C’est du temps que beaucoup de prestataires ne facturent pas parce qu’il est difficile à justifier sur un devis, et c’est exactement le temps qui décide si le nouveau système sera utilisé ou contourné.
Un système qui ne connaît pas ces exceptions ne se fait pas rejeter bruyamment. Il se fait contourner : on ressort un tableau à côté pour noter ce que le logiciel n’accepte pas, et l’entreprise se retrouve avec deux systèmes au lieu d’un.
Le papier n’est pas un vestige, c’est un registre
Dans beaucoup d’entreprises algériennes, le papier n’est pas ce qui reste d’avant l’informatique. C’est le support qui fait foi, et il contient des informations qui ne sont dans aucun logiciel.
Le cahier de livraison signé par le client, le registre des entrées de stock tenu par le magasinier, le classeur des bons de commande annotés à la main : ces objets tranchent les litiges. Quand le logiciel et le cahier ne disent pas la même chose, c’est le cahier qu’on croit, et cela a une raison — il porte une signature.
Une migration qui ignore cette couche remplace un système complet par un système partiel. Les équipes s’en aperçoivent en quelques semaines, et elles font la seule chose raisonnable : elles gardent le papier. L’entreprise a alors payé un nouveau logiciel et conservé l’ancienne charge de travail.
Ici encore, nous n’avons pas de chiffre national à citer sur la part des entreprises concernées, et nous préférons le dire que produire une estimation dont l’origine serait notre propre impression. La question à poser dans votre entreprise est simple et se répond en une journée : en cas de litige avec un client, quel document sortez-vous ?
Si la réponse est un papier, alors ce papier fait partie du système à migrer, et il faut décider explicitement de ce qu’il devient — numérisé, remplacé par une signature électronique, ou conservé tel quel en parallèle. Ne pas décider revient à décider de le garder.
Le remplaçant sera consulté sur un téléphone
Le système que vous remplacez a été conçu pour un poste fixe, dans un bureau, sur un écran large. Son remplaçant sera regardé ailleurs, et cela change ce qu’il faut lui demander.
L’observatoire du marché de l’internet de l’ARPCE recense pour le deuxième trimestre 2025 quelque 59,10 millions d’abonnements internet en Algérie, dont 88,71 % de mobiles et 11,29 % de fixes. Ce rapport ne décrit pas un usage de loisir : c’est aussi la façon dont votre magasinier, votre commercial en déplacement et votre gérant consultent ce que le système contient.
La conséquence n’est pas qu’il faut une application mobile. C’est que les écrans réellement utilisés au quotidien — consulter un stock, retrouver un client, valider une livraison — doivent fonctionner sur un téléphone, tandis que la saisie lourde peut rester au bureau.
C’est aussi un argument de migration à part entière, et souvent le plus solide des quatre conditions au titre du « il vous empêche de faire une chose que vous devez faire ». Un logiciel installé sur un seul poste ne peut pas être consulté depuis un entrepôt, et aucune mise à jour ne changera cela.
Enfin, la connexion est intermittente plutôt qu’absente. Un système qui exige le réseau pour afficher une information déjà connue sera jugé cassé par ses utilisateurs, même quand il fonctionne comme prévu.
- Abonnements mobiles88.71%
- Abonnements fixes11.29%
ARPCE, observatoire du marché de l’internet, 2e trimestre 2025
Pourquoi la bascule d’un seul week-end échoue
Le scénario est toujours le même et il est toujours proposé pour de bonnes raisons : on arrête l’ancien le vendredi soir, on migre pendant le week-end, on démarre le nouveau le lundi. C’est plus court, moins cher sur le papier, et cela évite de faire tourner deux systèmes.
Ce que ce plan suppose est que tout ce qui pouvait mal se passer a été découvert avant. Or la seule chose qui découvre réellement les écarts est l’usage : des utilisateurs réels, sur des cas réels, comparant deux résultats. Un week-end ne contient pas cela.
Le mode de défaillance n’est pas non plus celui qu’on imagine. Ce n’est presque jamais une panne franche, qui serait gérable — on reviendrait en arrière. C’est un écart silencieux : un total de stock qui diffère de quelques unités, une remise appliquée deux fois, un solde client qui ne correspond plus. On s’en aperçoit des semaines plus tard, quand les deux systèmes ont divergé et qu’il n’y a plus de retour possible.
Le fonctionnement en parallèle est la réponse, et son coût est réel : pendant quelques semaines, certaines saisies se font deux fois. C’est le prix de la seule chose qui protège vraiment, qui est de pouvoir comparer les chiffres des deux systèmes jour après jour jusqu’à ce qu’ils coïncident.
Nous refusons les bascules d’un seul coup, et nous le disons avant le devis plutôt qu’après. Ce n’est pas une position de principe : c’est le seul risque de ce métier qui ne se rattrape pas une fois réalisé.
Les six questions à poser à qui vous propose une migration
Voici ce qu’il faut demander, et ce que les réponses vous apprennent. Elles fonctionnent avec nous comme avec n’importe qui d’autre, et c’est l’intérêt de les écrire ici.
Avez-vous extrait mes données avant de me donner ce prix ? Si non, le prix est une hypothèse. Que se passe-t-il si l’extraction est incomplète — qui paie le travail supplémentaire ? La réponse doit être dans le contrat, pas dans la conversation.
Combien de jours prévoyez-vous pour observer mes équipes au travail ? Un devis qui ne contient pas ces jours-là contient l’hypothèse que le cahier des charges est complet, ce qui n’arrive jamais. Et : comment vérifiez-vous l’encodage des données en arabe ? Une réponse vague ici annonce des noms illisibles en production.
Combien de temps les deux systèmes tourneront-ils ensemble ? Toute réponse inférieure à quelques semaines mérite une justification précise. Enfin : que devient l’ancien système une fois arrêté ? La bonne réponse contient le mot « archive » et décrit un format que vous pourrez relire sans le logiciel d’origine.
Une septième question vaut pour nous aussi : à quelle condition me diriez-vous de ne pas faire ce projet ? Un prestataire qui n’a pas de réponse à cela n’a pas de critère, et un prestataire sans critère dira toujours oui.
Ce que nous faisons de ce sujet, et ce que nous refusons
Notre travail sur ce sujet commence toujours par le même acte, et ce n’est pas un développement : nous sortons vos données. Complètement, sur vos fichiers réels, et nous vous montrons ce qui manque. Tant que cela n’est pas fait, nous ne donnons pas de prix ferme, parce que nous ne saurions pas ce que nous vendons.
Nous refusons trois choses, et elles nous coûtent des projets. Nous ne faisons pas de bascule d’un seul week-end, même demandée, même avec une décharge. Nous ne chiffrons pas une migration dont les données n’ont pas été extraites. Et nous ne prenons pas de projet où les personnes qui utilisent le système ne peuvent pas être libérées pour nous parler, parce que nous produirions un logiciel faux avec votre argent.
Il y a aussi une part de ce travail que vous pouvez faire sans nous, et qui est celle qui a le meilleur rapport coût-résultat : passer les quatre conditions en revue. Trois se vérifient en une après-midi et sans compétence technique — la date de fin de support de votre système d’exploitation se lit sur le site de l’éditeur, le nombre de personnes qui savent le faire fonctionner se compte, et ce qu’il vous empêche de faire, vous le savez déjà.
Nous ne promettons aucun chiffre sur ce que la migration vous fera gagner. Les gains dépendent de ce que vos équipes feront du temps libéré, ce qui ne nous appartient pas, et toute agence qui vous annonce un pourcentage de productivité sur ce type de projet l’a choisi pour qu’il tienne dans une diapositive.
Enfin, la réponse honnête reste souvent non. Si votre système reçoit encore ses correctifs, si plusieurs personnes savent l’utiliser, s’il ne bloque rien et si ses données sortent, gardez-le. Nous vous le dirons, et cela nous coûtera un projet dont vous n’aviez pas besoin.
Questions fréquentes
Notre logiciel a quinze ans. Est-ce trop vieux ?
L’âge n’est pas un critère. Vérifiez les quatre conditions : correctifs de sécurité, nombre de personnes qui savent s’en servir, blocage sur un besoin actuel, sortie des données. Si aucune ne s’applique, quinze ans n’est pas un problème.
Combien coûte une migration ?
Cela dépend presque entièrement de l’état des données, et c’est pourquoi un prix donné avant l’extraction n’a pas de valeur. La fourchette entre une base propre et une base fermée va facilement du simple au triple.
Peut-on migrer sans arrêter l’activité ?
Oui, et c’est la seule façon dont nous procédons. Les deux systèmes tournent en parallèle et l’ancien ne s’arrête que lorsque plus personne ne s’en sert.
Notre éditeur a disparu. Sommes-nous bloqués ?
Pas nécessairement. Ce qui compte est l’accès à la base de données, pas au code source. Beaucoup de bases anciennes se lisent avec des outils standard ; le blocage réel est une base chiffrée dont personne n’a la clé.
Faut-il tout reprendre, ou seulement les données récentes ?
C’est une décision à prendre explicitement et par écrit. Reprendre dix ans d’historique coûte plus cher que trois ans ; ne pas le reprendre signifie garder l’ancien système accessible en lecture, ce qui a aussi un coût.
Combien de temps les deux systèmes doivent-ils tourner ensemble ?
Jusqu’à ce qu’ils donnent les mêmes chiffres sur une période complète — au minimum un cycle de facturation entier, et davantage si votre activité est saisonnière.
Où nous intervenons
Trois des quatre conditions se contrôlent en un après-midi, sans nous et sans dépense. Si aucune ne s’applique, ce chantier n’a pas lieu d’être ouvert cette année.
- Nous commençons par vérifier que vos données peuvent sortir, avant toute autre chose.
- Nous procédons par étapes, jamais par un basculement unique un week-end.
- Nous vous rendons l’export dans un format lisible sans le logiciel d’origine.
Un système qui reçoit encore ses correctifs et que plusieurs personnes savent faire fonctionner ne se remplace pas : la réponse honnête ici est souvent non.
À lire ensuite
La bascule : faire tourner l’ancien et le nouveau en même temps
Remplacer un système ne se fait pas un week-end. Cela se fait pendant une période où les deux tournent, et cette période se conçoit.Reprendre un système dont personne ne répond : ce qui se récupère, ce qui se reconstruit
Votre site tourne, votre logiciel tourne, et celui qui les a faits ne répond plus. Une grande partie de la réponse est publique et gratuite.Après la v1 : ce que coûte vraiment de faire évoluer un logiciel sur mesure
Un logiciel sur mesure ne se livre pas, il se met en service. Tout ce qui compte ensuite se joue sur la façon dont vous demandez un changement.
Parlons de votre projet
Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.