Réponse courte. On ne réécrit pas un logiciel de gestion en un week-end et on ne le remplace pas par un produit vide. On reprend toutes les données, douze ans de factures, de clients, d'articles et de stocks ; on fait tourner le premier module en parallèle de l'ancien pendant quelques semaines en comparant les totaux au dinar près ; on bascule un module à la fois avec un retour arrière possible ; et on n'éteint l'ancien logiciel que quand plus personne ne l'ouvre. Entre-temps, la facturation ne s'arrête pas un seul jour.
Ce guide s'adresse au distributeur, au grossiste, à l'industriel, à la clinique, à l'école, à la chaîne de magasins dont le logiciel de gestion a été écrit il y a dix ou quinze ans en WinDev, en Access, en Delphi ou en Visual Basic, ou qui vit encore dans des fichiers Excel partagés, et au propriétaire installé en France qui suit l'entreprise familiale par AnyDesk sur le PC du bureau. Il dit ce que les calendriers de Microsoft et les chiffres de StatCounter imposent, en quoi une migration ressemble à une greffe et non à une démolition, et ce que la plateforme web et mobile apporte que le logiciel de 2013 ne pouvait pas donner.
Ce que les chiffres disent
Le calendrier est fixé par Microsoft. Windows 10 a atteint sa fin de support le 14 octobre 2025 ; depuis, les PC qui ne sont pas inscrits au programme payant de mises à jour de sécurité étendues ne reçoivent plus de correctif. Pour les entreprises, ce programme coûte 61 dollars par poste la première année, un prix qui double chaque année, pour trois ans au maximum ; pour les particuliers, Microsoft indique que les mises à jour s'arrêtent le 12 octobre 2027 quelle que soit la date d'inscription. Et Windows 11 n'accepte pas tous les PC : selon les critères publiés par Microsoft, il faut une puce TPM 2.0 et un processeur récent, ce qui exclut une partie des machines de 2017 ou avant, sur lesquelles tournent justement les vieux logiciels. Les mêmes échéances touchent le reste de la pile : Office 2016 et 2019, donc Access 2016 et 2019, ont perdu leur support le 14 octobre 2025 ; SQL Server 2016 a atteint la fin de son support étendu le 14 juillet 2026 ; la troisième et dernière année de mises à jour étendues de Windows Server 2012 R2 s'est terminée en octobre 2026.
L'Algérie est en retard sur cette bascule, et ce retard est concentré dans les entreprises. D'après StatCounter, en octobre 2026, 36,96 % des PC de bureau en Algérie tournaient encore sous Windows 10, contre 61,81 % sous Windows 11 ; dans le monde, la part de Windows 10 n'était plus que de 25,13 %. Ces chiffres mesurent le trafic web, pas le parc des entreprises, et se lisent comme un ordre de grandeur ; mais ce que nous voyons dans les sociétés que nous rencontrons va dans le même sens : le PC du logiciel de gestion est souvent le plus ancien de l'entreprise, précisément parce qu'on n'ose pas y toucher. Le précédent est connu : en mai 2017, le rançongiciel WannaCry a touché, selon Europol, plus de 200 000 victimes dans au moins 150 pays, en exploitant une faille déjà corrigée sur les Windows à jour et ouverte sur les autres.
Le reste du contexte est celui que nous citons dans tous nos guides 2027 : 51,63 millions d'abonnements 4G et 5G au deuxième trimestre 2026 selon l'ARPCE, des vendeurs et des livreurs qui ont tous un téléphone, et des dirigeants qui veulent voir les chiffres depuis l'autre site ou depuis la France. C'est là que le vieux logiciel bloque : il est monoposte ou en réseau local, il ne connaît qu'un dépôt, il n'a pas d'application, et son éditeur, s'il existe encore, facture chaque état supplémentaire. WinDev, l'atelier de l'éditeur français PC SOFT, diffusé selon lui dans plus de 146 pays, est très présent depuis vingt ans dans les logiciels de gestion vendus en Algérie et en France, d'après ce que nous voyons ; sa base HFSQL se lit avec ses propres outils, et c'est la première chose à vérifier avant de signer quoi que ce soit.
Une migration qui n'arrête pas l'activité, en six moments
Une migration se juge sur six moments, de l'inventaire à l'extinction de l'ancien logiciel, et le premier est celui que l'on bâcle.
L'inventaire dure une à deux semaines et ne demande pas une ligne de code : la liste des écrans utilisés et de ceux qui ne le sont plus, des documents imprimés chaque jour, chaque semaine et chaque fin de mois, des personnes qui saisissent et de ce qu'elles font à côté, le cahier, le fichier Excel du dépôt 2, la photo WhatsApp du stock. On note aussi où est la base, qui en a le mot de passe, et ce que dit le contrat avec l'éditeur. L'extraction est le moment technique : la base est lue avec les outils de son format, HFSQL, Access, SQL Server, ou par export écran si elle est verrouillée, et copiée en entier, douze ans compris, dans une base ouverte ; le script d'extraction est rejoué autant de fois que nécessaire, parce que les données continuent de changer jusqu'à la bascule.
Le premier module en parallèle est en général les ventes et le stock, parce que c'est là que sont les factures. Pendant quelques semaines, les mêmes opérations sont saisies dans les deux systèmes, ou rejouées automatiquement de l'ancien vers le nouveau, et le rapprochement compare chaque semaine les totaux par mois, par client et par article : une différence est une règle oubliée, pas un détail. La bascule se fait pour ce module seul, l'ancien restant disponible en lecture ; puis la méthode est reprise pour les achats, la caisse, les livraisons. L'extinction vient en dernier : l'ancien logiciel passe en lecture seule, une archive est conservée, le PC est débranché, et le contrat avec l'éditeur peut être clos.
Pourquoi on ne réécrit pas tout d'un coup
Le logiciel est jetable ; les données et les règles ne le sont pas. La plateforme les reprend et ajoute ce que le logiciel ne pouvait pas faire.
Deux textes que tout développeur connaît disent la même chose depuis vingt-cinq ans. Le 6 avril 2000, Joel Spolsky écrivait que réécrire un logiciel à partir de zéro est la pire erreur stratégique qu'une entreprise puisse commettre, avec l'exemple de Netscape, restée près de trois ans sans sortir de version pendant sa réécriture ; en 2004, Martin Fowler décrivait la « figue étrangleuse », un nouveau système qui pousse autour de l'ancien, fonction par fonction, jusqu'à le remplacer. La migration d'un logiciel de gestion suit cette seconde voie. La couche données est reprise en entier et devient l'actif de l'entreprise : une base ouverte, à son nom, copiée chaque nuit, exportable à la demande. La couche règles est réécrite, mais chaque règle est rejouée sur les factures passées jusqu'à ce que les totaux coïncident, parce que la remise cumulée, l'arrondi et le stock négatif toléré sont souvent dans le code et nulle part ailleurs.
La couche web reproduit d'abord ce que les utilisateurs font déjà, avec les documents imprimés à l'identique, puis ajoute les trois dépôts dans la même base, les rôles par personne et le journal des actions. La couche mobile est ce que le logiciel de 2013 n'avait pas : la prise de commande chez le client, le stock du dépôt sur le téléphone du livreur, l'encaissement, hors ligne quand le réseau manque, et les chiffres du jour sur le téléphone du dirigeant. La couche direction vient en dernier et profite de tout l'historique : le tableau de bord par dépôt, que nous décrivons dans le guide sur le tableau de bord et la business intelligence, et un agent IA qui répond en français ou en arabe à « quels clients ont baissé de 30 % cette année » sur douze ans de factures, ce qu'aucun état imprimé ne faisait ; nous expliquons où un agent IA rapporte dans une entreprise algérienne dans un guide à part.
«Le logiciel est jetable ; les données et les règles ne le sont pas.»
Un exemple chiffré
Un exemple sur des hypothèses, à refaire avec vos chiffres : un distributeur, trois dépôts, quatorze utilisateurs, un logiciel WinDev de 2013 sur un serveur sous l'escalier.
Les données. 68 000 factures sur douze ans, 3 900 clients, 2 600 articles, lus dans la base HFSQL avec les outils de l'éditeur et copiés en entier dans une base ouverte ; le script tourne en vingt minutes et peut être rejoué chaque nuit jusqu'à la bascule. Les modules. Cinq, dans l'ordre des factures : ventes et stock, achats, caisse et encaissements, livraisons sur mobile, tableau de bord ; chacun n'est commencé qu'une fois le précédent basculé. Le parallèle. Quatre semaines pour le premier module, pendant lesquelles les ventes de l'ancien sont rejouées chaque nuit dans la plateforme ; 36 totaux mensuels, trois ans par dépôt, comparés au dinar près, et les deux écarts trouvés dans cet exemple sont deux règles d'arrondi que personne n'avait écrites.
L'arrêt. Zéro jour : à aucun moment une facture n'a dû attendre, parce que l'ancien logiciel est resté disponible jusqu'à ce que chaque module ait été rapproché. Ce que l'entreprise obtient à la fin. Les trois dépôts dans la même base au lieu de trois copies réconciliées par e-mail, quatorze utilisateurs avec chacun son rôle, les vendeurs qui prennent la commande sur leur téléphone, le dirigeant qui voit les ventes du jour depuis Marseille, et douze ans de factures interrogeables en une phrase. Le prix et le délai dépendent du nombre de modules, de l'état de la base et de ce qu'il faut reproduire à l'identique ; nous donnons le prix total avant de commencer, comme dans tous nos guides.
Six façons de perdre une migration
Six façons de perdre, dont trois tiennent à la méthode et trois à ce que personne n'a regardé avant de commencer.
Le week-end de tout ou rien est la façon la plus courante de revenir à l'ancien logiciel pour six mois : une facture ne sort pas le lundi, les vendeurs rouvrent l'ancien, et la plateforme devient « le truc qu'on essaiera plus tard ». Les données nettoyées à la main, c'est-à-dire reprises à moitié, condamnent la plateforme à vivre à côté de l'ancien, ouvert « pour consulter » ; dans dix-huit mois, il sera encore là. Les règles cachées ne se découvrent que par le rapprochement ; c'est pour cela qu'il est chiffré et hebdomadaire, et non une relecture d'écrans.
Le rapport que personne n'a mentionné est en général l'état imprimé pour le gérant ou le comptable ; il faut le demander au moment de l'inventaire, en regardant ce qui sort de l'imprimante une fin de mois. L'éditeur qui garde la base se traite avant tout engagement : la base se lit-elle avec ses propres outils, sinon par export écran, et le contrat permet-il de la copier ; nous décrivons le cas extrême dans le guide sur l'application bloquée chez un développeur qui a disparu. Les habitudes enfin : une saisie au clavier qui prend deux fois plus de temps est un échec, quelle que soit la qualité du reste ; les écrans se dessinent avec les personnes qui les utiliseront, et le pilote se fait sur un dépôt avant les autres.
Ce qu'on garde, ce qu'on refait
La migration ne jette pas quinze ans de travail : elle garde ce qui a de la valeur et refait ce que le logiciel ne pouvait pas faire.
On garde toutes les données et leur numérotation, le fond des règles telles que l'entreprise les pratique, l'ordre des champs et les raccourcis auxquels les utilisateurs tiennent, les documents imprimés au format que les clients connaissent, et les gestes qui marchent : la facture en trois clics, la fin de journée en dix minutes. On refait le format des données, une base ouverte et sauvegardée ; la forme des règles, écrites et testées, modifiables sans rappeler le développeur ; les écrans pour tout ce qui n'existait pas, le web, le mobile, les rôles, les dépôts ; la production des documents, générés et envoyés par e-mail ou WhatsApp ; et tous les contournements, le cahier, le fichier Excel, la photo du stock, qui disparaissent parce que la plateforme fait ce qu'ils compensaient.
La seule ligne où l'on ne garde rien est le serveur sous l'escalier. L'hébergement se choisit avec l'entreprise, selon ses contraintes et ses clients, avec des copies hors site, un accès par rôle et un journal de qui a fait quoi ; nous détaillons ce qu'une plateforme coûte à faire vivre, serveurs, stores et mises à jour, dans le guide sur le coût d'une année d'application.
«Des données reprises à moitié condamnent la plateforme à vivre à côté de l'ancien logiciel au lieu de le remplacer.»
Vu en France : ce qui se transpose, et ce qui ne se transpose pas
Les PME françaises ont fait cette migration avant les algériennes, poussées par leurs éditeurs, qui ont arrêté les versions de bureau de leurs logiciels de gestion au profit d'abonnements en ligne, et par une réforme : à partir du 1er septembre 2026, toutes les entreprises françaises assujetties à la TVA doivent pouvoir recevoir des factures électroniques, et les PME devront en émettre à partir du 1er septembre 2027, selon le calendrier publié par l'administration ; un logiciel de 2013 sans connexion ne le fait pas. Eurostat comptait 45,2 % des entreprises de l'Union européenne achetant des services en nuage en 2023, 4,2 points de plus qu'en 2021. Le résultat se voit dans n'importe quelle PME française : le logiciel est dans le navigateur, le comptable y a son accès, le dirigeant regarde ses chiffres sur son téléphone, et le serveur dans le placard a disparu.
Ce qui se transpose en Algérie : la méthode, données d'abord, un module à la fois, rapprochement chiffré ; la propriété des données au nom de l'entreprise ; l'accès par rôle et par téléphone. Ce qui ne se transpose pas : le produit lui-même. Les offres en ligne des éditeurs français se paient par carte internationale, un problème que nous avons décrit dans le guide sur le paiement du cloud depuis l'Algérie ; elles ne connaissent ni le dinar, ni les documents locaux, ni la facture telle que vos clients la lisent, et elles ne font pas le mobile terrain hors ligne. En Algérie, la migration passe par une plateforme construite sur les données de l'entreprise, avec les documents à l'identique, l'encaissement local et le terrain.
Depuis la France : suivre l'entreprise familiale sans AnyDesk
Le cas que nous rencontrons le plus souvent chez les propriétaires installés en France : l'entreprise familiale à Sétif ou à Oran tourne sur un logiciel de gestion de 2012, et le fils ou la fille qui vit à Lyon la suit en se connectant le soir au PC du bureau par AnyDesk ou TeamViewer, quand le PC est allumé et que personne n'est dessus. Ce n'est pas un accès à distance, c'est une télécommande sur une machine ; il n'y a ni rôle, ni journal, ni version mobile, et le jour où le disque du PC lâche, tout est perdu. La migration transforme ce bricolage en une plateforme : les mêmes données, un compte pour le propriétaire avec les chiffres du jour et les alertes sur le téléphone, un compte pour le gérant sur place avec la saisie, un pour le comptable avec les états ; nous avons décrit cette organisation dans le guide sur gérer son commerce en Algérie depuis la France.
Le fondateur de la diaspora qui reprend une entreprise existante, par héritage ou par rachat, part de la même question : qu'est-ce qu'il y a dans le logiciel, qui a la base, et qu'est-ce qui dépend d'une seule personne. L'inventaire du moment 01 est aussi un audit de reprise ; nous le rendons par écrit, avec les trois options, migrer, remplacer par un produit du marché, ou garder et sécuriser, et leur prix total, avant toute décision.
Qui vous êtes, par où commencer
Le distributeur ou le grossiste commence par les ventes et le stock, parce que c'est là que sont les factures et les trois dépôts ; les livraisons sur mobile viennent au deuxième module. L'industriel commence par les achats, le stock de matières et les ordres de fabrication que son logiciel suit déjà, puis ajoute la maintenance et le terrain ; nous décrivons la GMAO dans un guide à part. La clinique ou le cabinet commence par le dossier patient et la facturation, avec la confidentialité par rôle dès le premier jour, puis le rendez-vous en ligne. L'école privée commence par les inscriptions et les paiements par tranches, puis l'espace parents sur mobile.
La chaîne de magasins commence par la caisse et le stock, magasin par magasin, parce que le logiciel de 2013 ne connaissait qu'un point de vente ; nous décrivons la caisse de 2027 dans un guide à part. Le propriétaire en France commence par l'inventaire et la copie de la base, c'est-à-dire par mettre les données à l'abri avant tout le reste, puis par le tableau de bord sur son téléphone, parce que c'est ce qui lui manque le plus. Dans tous les cas, la première semaine est la même : savoir ce qu'il y a dans le logiciel, et en avoir une copie à son nom.
Le calendrier 2027
Une migration module par module tient dans une année, et ne bascule rien pendant le ramadan, qui commence vers le 8 février 2027.
Janvier : l'inventaire et l'extraction. Les écrans, les rapports, les personnes ; la base lue et copiée en entier ; un premier rapprochement des totaux pour savoir si la base est saine. Février à avril : le premier module en parallèle. Ventes et stock saisis dans les deux systèmes ou rejoués chaque nuit, totaux comparés chaque semaine, règles oubliées retrouvées une à une ; le ramadan tombe dans cette période, et on ne bascule rien pendant. Mai : la bascule du module 1. Rapprochement final, ancien logiciel en lecture seule pour ce module, retour arrière possible pendant un mois.
Juin à septembre : les modules 2 et 3. Achats, caisse et encaissements, puis les livraisons sur le téléphone des vendeurs et des livreurs, avec la même méthode et des parallèles plus courts, parce que les données et les habitudes sont déjà dans la plateforme. Octobre et novembre : la direction. Les états de fin de mois reproduits et vérifiés sur un exercice entier, le tableau de bord par dépôt, l'agent IA sur l'historique. Décembre : l'extinction. Lecture seule, archive conservée, PC débranché, contrat éditeur clos, et un exercice 2028 qui s'ouvre dans la plateforme seule.
Ce qui fait échouer une migration
- Commencer par les écrans. Dessiner la nouvelle interface avant d'avoir lu la base et compté les factures : la migration devient un projet de design, et les données attendent.
- Reprendre seulement l'année en cours. Les anciens soldes et l'historique restent dans l'ancien logiciel, qu'on garde « pour consulter » ; il est encore là dans deux ans.
- Basculer tout un week-end. Une facture qui ne sort pas le lundi, et six mois de retour à l'ancien.
- Rapprocher à l'œil. Relire des écrans au lieu de comparer des totaux par mois, par client et par article ; les règles cachées passent.
- Ne pas regarder l'imprimante. L'état de fin de mois du gérant n'a été mentionné par personne ; la plateforme est jugée inutilisable à la première clôture.
- Signer sans savoir qui a la base. Un mot de passe que l'éditeur ne donne pas, un format fermé, et la migration commence par une négociation.
- Former après la bascule. Les vendeurs découvrent la saisie le jour où elle compte ; le pilote sur un dépôt, avec eux, évite cela.
Questions fréquentes
Les questions que nous recevons des dirigeants dont le logiciel de gestion a dix ans ou plus.
- Faut-il abandonner WinDev, Access ou Delphi, ou peut-on moderniser le logiciel existant ?
- Les deux existent. Si le code source est disponible, que l'éditeur répond et que le besoin est seulement un nouvel état ou un correctif, moderniser l'existant est raisonnable et coûte moins. Si le besoin est plusieurs sites, le mobile, l'accès à distance, l'IA sur l'historique, ou si le code et l'éditeur ne sont plus là, la plateforme web et mobile construite sur les données reprises est la voie. L'inventaire du moment 01 permet de trancher par écrit, avec les trois options et leur prix total.
- Notre éditeur ne veut pas nous donner la base de données. Que faire ?
- Commencer par le contrat et par le format. Une base HFSQL, Access ou SQL Server se lit en général avec les outils de son format si l'on a accès au fichier, même sans l'éditeur ; si elle est chiffrée ou protégée par un mot de passe qu'il refuse de donner, les données se reprennent par export écran et par les états imprimés, plus lentement mais complètement. Dans tous les cas, la première action est une copie des fichiers de la base au nom de l'entreprise, avant toute discussion. Le guide sur l'application bloquée chez un développeur disparu décrit la procédure actif par actif.
- Combien de temps dure une migration ?
- Environ quatre à six mois pour le premier module, inventaire et extraction compris, sur un logiciel de gestion classique ; les modules suivants vont plus vite parce que les données et les habitudes sont déjà dans la plateforme. Une entreprise à trois dépôts et cinq modules tient dans l'année, comme dans le calendrier ci-dessus. Nous détaillons les délais réels dans le guide sur le temps de développement d'une plateforme.
- Peut-on garder Excel pendant la migration ?
- Oui, et c'est souvent nécessaire : les fichiers Excel du dépôt 2 ou du commercial sont des sources de données comme les autres, lues et reprises par script. Ce qui disparaît après la bascule, ce sont les contournements, le fichier qui compense ce que le logiciel ne faisait pas ; les exports Excel depuis la plateforme restent disponibles à tout moment pour le comptable et le dirigeant.
- Vaut-il mieux migrer vers un ERP du marché comme Odoo que vers une plateforme sur mesure ?
- Cela dépend de la distance entre vos règles et celles du produit. Un ERP du marché convient quand l'entreprise accepte de travailler comme le produit le prévoit et n'a pas de terrain mobile particulier ; la plateforme sur mesure convient quand les règles, les documents et le terrain sont les vôtres et que vous voulez les garder. Dans les deux cas, les données se reprennent de la même façon. Nous comparons les deux voies dans le guide Odoo ou ERP sur mesure.
- Si on passe seulement les PC sous Windows 11, le problème est-il réglé ?
- Le problème de sécurité du poste, oui, si le PC accepte Windows 11, ce que les critères de Microsoft, puce TPM 2.0 et processeur récent, n'assurent pas pour les machines anciennes. Le reste ne change pas : le logiciel reste monoposte ou en réseau local, sans mobile, sans accès à distance, avec une base que seul l'éditeur sait ouvrir. Changer de PC est une dépense ; migrer les données vers une plateforme est un investissement, et les deux peuvent se faire la même année, dans cet ordre : copie de la base, puis migration, puis renouvellement des postes.