Réponse courte. Les en-têtes du fournisseur ne sont jamais les champs de l'application : une table de correspondance, mémorisée par fournisseur et versionnée, relie chaque colonne à un champ avec une règle de lecture, virgule décimale, espaces dans les codes, lignes de titre et de totaux à ignorer. Avant qu'une seule valeur ne soit écrite, un essai à blanc lit tout et rend un verdict par ligne : acceptée, avertissement à confirmer, ou rejet avec la raison. Le gérant confirme, et l'application se fait en arrière-plan par lots, avec une progression visible et une reprise après coupure ; chaque ligne porte une clé d'idempotence, et l'empreinte du fichier fait qu'un fichier redéposé ne fait rien. Chaque valeur remplacée est conservée avec le numéro d'import, ce qui permet le retour arrière en un geste. Un en-tête inconnu déclenche une question, pas un import faux. Six semaines, dont la première sans code.
Ce guide s'adresse au gérant d'un grossiste, d'une pharmacie ou d'un commerce qui reçoit des tarifs, des catalogues et des feuilles de comptage en Excel chaque semaine, au fondateur installé en France dont l'équipe à Alger passe le lundi matin à copier-coller, et au responsable qui a déjà dû corriger un import faux à la main. Il ne redit pas comment on reprend un ancien fichier une fois pour toutes au moment d'une migration, décrit dans le guide sur la reprise de données, ni comment on se branche à un logiciel qui a une API, décrit dans le guide sur l'intégration ; il décrit ce qui se construit pour les fichiers qui reviennent, et il prolonge notre page sur l'ingénierie logicielle.
Le fichier du fournisseur, colonne par colonne
La figure montre un tarif fournisseur tel qu'il arrive, et ce que l'application en fait colonne par colonne et ligne par ligne, avant d'écrire quoi que ce soit.
Le fichier a une ligne de titre fusionnée, des en-têtes dans les mots du fournisseur, des prix écrits « 1 250,00 », un code-barres avec des espaces, une référence vide, un « N/D » et une ligne de totaux. Aucun de ces détails n'est une erreur du fournisseur : c'est un fichier fait pour être lu par un humain. La correspondance relie « Réf. » à la référence fournisseur, qui est la clé, « PU HT » au prix d'achat avec la règle de lecture française, « Code EAN » au code-barres avec le chiffre de contrôle vérifié ; les lignes de titre et de totaux sont ignorées par le modèle.
Chaque ligne reçoit un verdict : trois acceptées, dont une avec un code nettoyé ; une avec avertissement, parce que le prix monte de 40 % par rapport au dernier import et que le gérant a fixé ce seuil ; deux rejetées, référence vide et prix illisible, avec la raison. La correspondance est mémorisée pour ce fournisseur et réutilisée chaque semaine ; si une colonne change de nom, l'application demande au gérant de la relier, elle ne devine pas. Les données de la figure sont un exemple construit.
«Les en-têtes du fournisseur ne sont jamais les champs de l'application : une table de correspondance, mémorisée par fournisseur, fait le lien, et chaque colonne a une règle de lecture.»
Un import qui ne casse rien, en cinq couches
L'essai à blanc est la couche qui compte, mais il ne suffit pas : il faut une réception qui reconnaît le fichier, une correspondance qui dure, une application qui reprend, et un historique qui défait.
Réception. Dépôt par le gérant, boîte e-mail dédiée où le fournisseur envoie lui-même, ou dossier partagé ; formats .xlsx et .csv, détection de l'encodage et de la feuille, empreinte du fichier : le même fichier déposé deux fois n'est importé qu'une fois. Correspondance. Une table par fournisseur et par type de fichier : quelle colonne va dans quel champ, quelles lignes sont ignorées, quelle règle de lecture s'applique à chaque colonne ; mémorisée et versionnée, parce que les fournisseurs changent leurs modèles. Validation. L'essai à blanc lit tout et n'écrit rien ; verdict par ligne, seuils d'avertissement écrits, aperçu et rapport des rejets ; c'est la couche accentuée.
Application. Après confirmation seulement : en arrière-plan, par lots, avec une progression visible et une reprise après coupure ; une clé d'idempotence par ligne, selon la même mécanique que le guide sur le hors ligne, et chaque valeur remplacée conservée avec le numéro d'import. Historique. Journal des imports, qui, quand, quel fichier, combien de lignes et de rejets ; retour arrière d'un import en un geste ; rapport des rejets envoyé au fournisseur par WhatsApp ou e-mail, selon le guide sur les notifications. Qui peut importer et qui peut confirmer un avertissement sont des droits, selon le guide sur les rôles.
Un import, du dépôt au retour arrière
La figure suit un import de 1 842 lignes, du dépôt du fichier à l'annulation possible, avec le temps de chaque étape.
Le fichier est déposé, le modèle du fournisseur est reconnu, et l'essai à blanc rend en deux secondes un verdict par ligne : 1 790 acceptées, 44 avertissements, 8 rejets. Le gérant voit les 44 avertissements, en confirme ou en écarte, et lance ; l'application se fait en arrière-plan par lots de 200, avec une barre de progression, et se termine en 38 secondes. Le journal enregistre l'import numéro 27, 1 790 prix mis à jour, et le rapport des 8 rejets part au fournisseur ; le gérant reçoit un message.
Deux mécanismes rendent l'import sûr. Le retour arrière : chaque valeur remplacée a été conservée avec le numéro d'import, et l'import 27 se défait en un geste, l'annulation étant elle-même un import journalisé. L'idempotence : la clé fournisseur, référence et empreinte du fichier fait qu'un fichier redéposé ne fait rien, et qu'une ligne déjà appliquée n'est pas réappliquée après une coupure au lot 6. Les nombres de lignes et les durées sont un exemple construit ; la durée dépend du volume et du serveur.
«Rien n'est écrit avant l'essai à blanc et la confirmation ; tout ce qui est écrit peut être défait en un geste.»
Le lundi matin, en six gestes
Ce que fait le gérant ou l'employé chargé des imports, dans l'ordre, et pourquoi le troisième geste est celui qui change tout.
Déposer le fichier, en le glissant, ou ne rien faire parce qu'il est arrivé seul par l'e-mail dédié. Vérifier le modèle : fournisseur reconnu, colonnes reliées ; si une colonne a changé, la relier, et le modèle passe en version suivante. Lire l'essai à blanc : acceptées, avertissements, rejets, aperçu des premières lignes ; c'est l'étape accentuée, celle qui n'existe pas dans un copier-coller. Trancher les avertissements : confirmer en un geste, ou écarter des lignes. Lancer, et fermer l'écran si on veut. Lire le journal : ce qui a changé, le rapport des rejets parti au fournisseur, et annuler si besoin.
Les cinq gestes mécaniques prennent deux minutes ; le troisième en prend cinq, et c'est lui qui évite une semaine de prix faux. Les prix importés alimentent le moteur de prix décrit dans le guide sur le devis, et les quantités d'une feuille de comptage deviennent des mouvements d'ajustement, selon le guide sur le stock.
Six situations réelles, et ce que l'application fait
Les six situations qu'on retrouve dans presque toutes les entreprises qui importent des fichiers chaque semaine, et la construction qui les règle.
Les deux premières lignes se règlent par la correspondance et les règles de lecture : un en-tête inconnu est une question, pas un décalage de colonne, et un prix à la française est lu comme tel. La troisième se règle par l'essai à blanc et un seuil écrit. Les deux suivantes se règlent par l'idempotence et les lots : l'empreinte du fichier et la clé par ligne empêchent le double import, et une coupure au milieu ne rejoue pas ce qui est fait. La dernière se règle par l'historique : chaque valeur remplacée est conservée, et l'import se défait en un geste. Aucune ne se règle par un employé plus attentif au copier-coller.
Vu ailleurs : les limites d'Excel, le CSV et les outils d'import du marché, et ce qui se transpose
Trois faits se transposent tels quels. Les limites d'Excel : une feuille compte au plus 1 048 576 lignes et 16 384 colonnes, et une cellule 32 767 caractères, selon la documentation de Microsoft ; ce qui se transpose, c'est qu'un fichier de dix mille lignes est petit pour l'application, mais que l'écran du gérant ne doit en afficher qu'un aperçu et un résumé. Le CSV : un format texte dont le séparateur, l'encodage et la marque d'ordre des octets varient selon l'outil qui l'a produit, et dont l'arabe sort illisible quand l'encodage est mal détecté ; ce qui se transpose, c'est une détection à la réception et un aperçu que le gérant lit avant de confirmer, selon les règles décrites dans le guide sur l'application bilingue. Les outils d'import des logiciels du marché : correspondance de colonnes, aperçu, rapport d'erreurs ; ce qui se transpose, c'est la mémorisation par fournisseur et le retour arrière, que les outils génériques ont rarement.
Ce que ces faits ne décident pas pour vous : vos champs cibles, vos seuils d'avertissement, qui confirme, et ce qu'on fait d'une ligne rejetée ; la première semaine du projet y répond, et c'est le gérant qui signe.
Les règles d'un import qui ne casse rien
Six règles, écrites la première semaine. Les en-têtes du fournisseur ne sont jamais les champs : une correspondance mémorisée fait le lien. Chaque colonne a une règle de lecture écrite. Rien n'est écrit avant l'essai à blanc et la confirmation. Un en-tête inconnu est une question, pas un import. Chaque ligne a une clé, et chaque fichier une empreinte. Chaque valeur remplacée est conservée avec le numéro d'import, et l'import se défait en un geste.
Et une règle de méthode : quand un fournisseur peut envoyer ses données autrement qu'en fichier, par une API ou un portail, on le fait, selon le guide sur l'API partenaires ; l'import de fichier est pour les fournisseurs qui n'ont que ça, et c'est la plupart.
Six entreprises, et l'import qui manquait
Six situations composées à partir de projets que nous rencontrons ; les noms sont génériques et les chiffres sont des exemples.
- Un grossiste alimentaire à Sétif, douze fournisseurs. Douze tarifs Excel par mois, douze modèles différents, un lundi par semaine à copier. La construction : une correspondance par fournisseur, e-mail dédié, essai à blanc, seuil d'avertissement à 20 %. Le lundi matin est passé de trois heures à vingt minutes, en exemple.
- Une pharmacie à trois officines. Le catalogue du répartiteur changeait chaque semaine et les prix d'achat étaient faux une semaine sur quatre. La construction : import du catalogue avec règle de lecture, rejets rapportés au répartiteur, retour arrière ; le cas est décrit dans le guide sur la pharmacie à trois officines.
- Un fondateur à Paris, boutique en ligne à Alger. Le fournisseur envoyait son fichier de stock le dimanche soir, et l'équipe le copiait le lundi avec des erreurs. La construction : dépôt par e-mail dédié, essai à blanc lisible depuis Paris, confirmation à distance ; la gestion à distance suit le guide sur le commerce depuis la France.
- Un distributeur à Oran, feuilles de comptage. Les inventaires tournants arrivaient en Excel depuis les dépôts et étaient saisis à la main. La construction : import des feuilles de comptage en mouvements d'ajustement avec motif, écarts au-delà d'un seuil en avertissement.
- Un détaillant à Constantine, portail B2B du grossiste. Le grossiste exportait les commandes en CSV et le détaillant les ressaisissait. La construction : import CSV avec détection d'encodage, correspondance mémorisée, rapprochement avec les bons de livraison ; le portail est décrit dans le guide sur le portail B2B.
- Une PME à Annaba, import doublé. Le même fichier de réceptions importé deux fois, quantités doublées, découvert à l'inventaire. La construction : empreinte du fichier, clé par ligne, retour arrière ; le double import est devenu impossible.
Le calendrier 2027
Six semaines pour une entreprise qui reçoit déjà des fichiers récurrents ; la première semaine se passe sans code.
Semaine 1, fichiers et règles : liste des fichiers récurrents, fournisseurs, fréquence, champs cibles, règles de lecture, seuils d'avertissement, qui confirme ; signés par le gérant. Semaine 2, réception et correspondance : dépôt, e-mail dédié, détection d'encodage et de feuille, table de correspondance par fournisseur mémorisée et versionnée. Semaine 3, essai à blanc : lecture complète sans écriture, verdict par ligne, seuils, aperçu, rapport des rejets.
Semaine 4, application et lots : confirmation, application en arrière-plan par lots, progression, reprise, idempotence, valeurs remplacées conservées. Semaine 5, historique et retour arrière : journal des imports, annulation en un geste, rapport des rejets envoyé au fournisseur. Semaine 6, mesure : taux de lignes rejetées par fournisseur, imports annulés, temps du lundi matin avant et après, sur le tableau de bord selon le guide sur le tableau de bord temps réel. Chaque semaine se termine par une démonstration, selon le guide sur la livraison sans casse.
Ce qui fait échouer un import
Cinq causes, vues dans des applications qu'on reprend. L'écriture immédiate : le fichier est lu et écrit dans le même geste, et l'erreur se découvre en production. La correspondance par position : la troisième colonne va dans le troisième champ, jusqu'au jour où le fournisseur en ajoute une. La lecture par défaut des nombres : « 1 250,00 » devient 1 ou 125 000. L'absence de clé : le même fichier importé deux fois double tout. L'absence d'historique : un import faux se corrige à la main pendant trois jours.
Et une cause de méthode : traiter chaque fichier comme un cas unique. Les fichiers qui reviennent méritent une correspondance mémorisée ; la première semaine est faite pour les lister.
Questions fréquentes
Les questions que posent les gérants et les fondateurs quand ils nous décrivent le lundi matin des imports.
- Pourquoi l'import Excel casse-t-il les données ?
- Parce que le fichier est écrit dans l'application au moment où il est lu, sans essai à blanc, avec une correspondance par position et une lecture des nombres par défaut. Une colonne ajoutée, un prix écrit à la française ou un fichier déposé deux fois suffisent. La construction qui règle cela : correspondance mémorisée, règle de lecture par colonne, essai à blanc, clé par ligne, retour arrière.
- Qu'est-ce qu'un essai à blanc ?
- Une lecture complète du fichier qui n'écrit rien et rend un verdict par ligne : acceptée, avertissement à confirmer, ou rejet avec la raison. Le gérant voit ce qui va changer avant que ça change, confirme ou écarte des lignes, puis lance. C'est l'étape qui n'existe pas dans un copier-coller.
- Que se passe-t-il si le fournisseur change ses colonnes ?
- Un en-tête inconnu déclenche une question au gérant, qui relie la colonne au bon champ ; rien n'est importé avant. La correspondance passe en version suivante et est réutilisée. L'application ne devine jamais une correspondance.
- Comment éviter d'importer le même fichier deux fois ?
- Par une empreinte du fichier et une clé d'idempotence par ligne, fournisseur, référence et empreinte. Le même fichier redéposé ne fait rien, et une ligne déjà appliquée n'est pas réappliquée après une coupure. C'est la même mécanique que pour la synchronisation hors ligne.
- Peut-on annuler un import ?
- Oui, en un geste, parce que chaque valeur remplacée est conservée avec le numéro de l'import. L'annulation restaure les valeurs précédentes et est elle-même un import journalisé. Un import faux se défait en une minute au lieu de trois jours de correction manuelle.
- Le fichier arrive par e-mail, faut-il le déposer à la main ?
- Non si une boîte e-mail dédiée est mise en place : le fournisseur y envoie son fichier, l'application le reçoit, reconnaît le modèle et prépare l'essai à blanc ; le gérant n'a plus qu'à lire et confirmer. Quand le fournisseur a une API, on la préfère au fichier.
- Combien de temps pour mettre cela en place ?
- Six semaines dans le calendrier type : une pour lister les fichiers et écrire les règles, une pour la réception et la correspondance, une pour l'essai à blanc, une pour l'application par lots, une pour l'historique et le retour arrière, une pour la mesure. Le délai dépend du nombre de fournisseurs et de la variété des fichiers.