En bref
- Le devis existe en trois exemplaires dans l'entreprise, et un seul fait foi
- La ressaisie ne se voit jamais au moment où elle se fait, seulement à la facturation
- Remplacer les trois outils par un seul déplace le problème au lieu de le régler
- Un export de fichier suffit à faire circuler la donnée, une API n'est pas indispensable
Contact KALAO
Sur quel travail voulez-vous être aidé en premier ?
On démarre toujours sur un seul sujet, celui qui pèse le plus aujourd’hui.
Une affaire se gagne. Le chargé d'affaires a monté le chiffrage dans son outil, avec ses sous-détails, ses temps unitaires et sa bibliothèque de prix. Le devis part au client, signé.
Commence alors un travail que personne ne revendique et que tout le monde fait. Quelqu'un reprend le devis et le retape dans l'outil de gestion, pour pouvoir éditer les situations et suivre le chantier. Quelques semaines plus tard, la comptabilité reprend les mêmes montants dans son plan de comptes. La même affaire vit désormais à trois endroits, sous trois formes, et une seule fait foi selon la personne à qui vous posez la question.
Ce n'est pas un problème d'organisation ni de rigueur. C'est un trou entre des outils qui font correctement leur travail chacun de leur côté.
Pourquoi un devis doit-il être saisi trois fois ?
Parce que les trois outils ne parlent pas du même objet. L'outil de chiffrage raisonne en ouvrages : un déboursé sec, des temps unitaires, des coefficients de frais généraux et de bénéfice. L'outil de gestion raisonne en lignes à facturer, avec des situations, des retenues et des échéances. La comptabilité raisonne en comptes et en journaux. Chacun est excellent dans son registre et aucun ne sait produire le format attendu par le suivant.
Tant que personne ne comble ce trou, c'est un humain qui fait le transport. Et un humain qui recopie trois cents lignes de bordereau introduit des écarts, non par négligence, mais parce que c'est ce que produit une tâche répétitive sans contrôle.
Quelles erreurs la ressaisie introduit-elle concrètement ?
Trois familles reviennent systématiquement, et aucune ne se voit le jour où elle se produit.
- Les unités. Un poste chiffré au mètre linéaire qui devient un mètre carré dans la gestion. La quantité passe, le prix unitaire passe, et l'écart n'apparaît qu'à la facturation.
- Les remises. Une remise accordée ligne à ligne au moment du chiffrage, reportée globalement dans la gestion. Les totaux concordent, mais plus aucun prix de vente unitaire ne correspond, ce qui rend la première situation incontrôlable.
- Les variantes. Une option chiffrée pendant l'étude mais non retenue par le client, qui repart quand même dans le devis de gestion parce que la ligne était restée dans le tableau source.
Le point commun de ces trois erreurs est qu'elles se découvrent en aval, quand la correction suppose un avenant ou un geste commercial.
Pourquoi le logiciel unique ne règle pas le problème
La réponse qu'on entend le plus souvent est de tout basculer dans une suite intégrée. C'est une réponse cohérente sur le papier, et c'est aussi celle qui échoue le plus souvent sur le terrain.
Une suite intégrée est rarement bonne partout. Elle est forte sur la gestion et faible sur le chiffrage fin, ou l'inverse. L'entreprise qui bascule tout découvre après quelques mois que son module le plus faible est devenu le maillon qui bloque, et que le chiffreur a rouvert un tableur en parallèle pour retrouver la finesse qu'il avait perdue. La ressaisie n'a pas disparu, elle a changé de place.
Faire circuler la donnée entre les outils que vous avez déjà coûte moins cher qu'un changement de système, et ne demande à personne de réapprendre son métier.
Comment la donnée circule-t-elle sans changer d'outil ?
Le principe est simple : un agent lit le fichier que produit votre chiffrage et rend le fichier qu'attend votre gestion, avec la bonne structure de colonnes, les bonnes unités et les remises ventilées comme il faut.
Deux portes existent selon vos outils. La première est l'export de fichier, au format tableur ou XML : elle fonctionne partout, y compris avec un logiciel de gestion ancien, et ne dépend de personne d'autre que vous. La seconde est l'API, quand l'éditeur en expose une. Onaya en propose une et revendique une interface avec une vingtaine de logiciels de comptabilité et de paie ; Batigest Connect, EBP et Codial se positionnent sur le même terrain. Quand cette porte existe, l'échange devient automatique et le fichier disparaît.
Dans les deux cas, c'est l'agent qui s'adapte à vos trames, pas vos trames qui s'adaptent à l'agent.
Comment savoir que rien ne s'est perdu en route ?
Un transfert sans contrôle ne vaut pas mieux qu'une ressaisie : il déplace simplement la confiance d'un humain vers une machine. Ce qui change la donne, c'est le contrôle rendu avec le transfert.
Trois vérifications couvrent l'essentiel. Le total du devis de gestion doit correspondre au total du chiffrage à l'euro près. Le nombre de lignes doit être identique des deux côtés. Chaque unité doit être la même, poste par poste. Un écart sur l'un des trois est signalé avec la ligne concernée, pas avec un message générique.
C'est ce rapport de contrôle qui permet de cesser de relire, et c'est lui qui fait la différence entre une passerelle utile et un import automatique auquel personne ne fait confiance.
Ce que cet agent ne fait pas
Il ne chiffre pas à votre place. Les prix, les coefficients et les temps unitaires restent les vôtres, et l'agent ne les discute jamais.
Il ne remplace ni votre outil de chiffrage ni votre outil de gestion. Il se place entre les deux et repart si vous changez l'un des deux.
Il ne tient pas votre comptabilité. Il prépare la matière dans le format attendu, la validation reste celle de votre comptable ou de votre cabinet.
Et il ne corrige pas un chiffrage faux. Un devis mal monté transféré sans erreur reste un devis mal monté.
Regardons votre dernier devis, de bout en bout
Apportez une affaire déjà signée. On suit le devis du chiffrage jusqu'à la comptabilité et on repère où la donnée se perd. Quarante-cinq minutes, sans engagement.
Réserver 45 minutes