Une société rachetée est opérationnelle le lendemain : trois à quatre heures d'intégration informatique, et le groupe les fait lui-même.

Le client est un groupe suisse alémanique, adossé à un fonds d'investissement, qui rachète des entreprises de nettoyage pour en faire un acteur de taille. Le modèle est simple à énoncer : acquérir, harmoniser la gestion, améliorer le résultat, recommencer.

Ce qui veut dire qu'intégrer une société n'est pas un projet exceptionnel chez eux — c'est une opération récurrente. Ils en rachètent à peu près une par mois. Chaque heure gagnée sur cette opération se multiplie donc par le nombre d'acquisitions à venir.

Et au départ, il n'y avait rien : nous sommes arrivés en même temps que le modèle. Le besoin était posé d'emblée — pouvoir absorber vite une entreprise qu'on vient d'acheter.

Nous travaillons avec eux en anglais.

C'est le détail qui explique tout le reste. Un plan comptable, c'est la liste des comptes d'une entreprise — un numéro, une désignation. Il existe bien un modèle suisse pour les PME, mais chacune l'adapte à son activité, et plus une société est développée, plus elle l'a spécifié. Résultat : deux entreprises du même métier n'ont pas le même plan comptable.

Quand on rachète une société, on hérite donc de sa comptabilité telle qu'elle est écrite. Et tant que son plan comptable ne ressemble pas à celui du groupe, aucune consolidation n'a de sens : les chiffres existent, mais ils ne parlent pas la même langue.

Le travail n'a pas porté sur la consolidation elle-même — l'outil la couvre en standard. Il a porté sur ce qui la rend possible : rapprocher les plans comptables des sociétés rachetées d'un plan de référence commun, puisqu'elles font toutes le même métier ; définir les comptes analytiques ; et fixer la manière de consolider, quel compte remonte dans quel compte.

L'intégration d'une société se réduit alors à une séquence connue : créer l'entité, importer le plan comptable, importer les balances d'ouverture mois par mois, poser les plans analytiques. Trois à quatre heures. Le lendemain, la société facture et paie ses salaires.

Le périmètre est volontairement resserré : les contacts, la comptabilité, les salaires. Pas les ventes — celles-ci sont émises depuis le portail métier du groupe, et nous avons construit côté outil les points d'entrée qui permettent à ce portail d'y déposer ses factures.

Les trois à quatre heures sont le temps informatique. Du côté du groupe, il reste à former les équipes de la société rachetée et à se déplacer : c'est plus long, et c'est leur métier.

La demande était légitime et séduisante : un bouton unique qui créerait la société et ferait tout le reste, pour ramener les trois à quatre heures à quelques minutes.

Nous ne l'avons pas construit, et nous le leur avons dit ainsi : au rythme d'une acquisition par mois, automatiser ce flux coûterait plus cher à développer que les heures qu'il ferait économiser. Ce serait rentable à trois rachats par mois. Pas à un.

C'est une position inconfortable à tenir — on refuse un développement qu'un client est prêt à payer. Mais la facture d'un développement inutile revient toujours, sous la forme d'un client qui se demande ce qu'il a acheté. Si le rythme des acquisitions augmente, le calcul change, et on le fera.

Aujourd'hui, quand le groupe rachète une entreprise, il l'intègre lui-même. Nous n'intervenons plus sur cette étape : notre travail se limite au support et aux nouvelles fonctionnalités. Ce n'est pas un désengagement, c'est l'objectif qui a été atteint — la base mise en place correspond à leur façon de travailler, elle est simple à utiliser, et ils ont appris à la reproduire.

Quatorze sociétés sont passées par là en deux ans, en partant de zéro.

Sur un client dont le métier est d'acquérir en série, une prestation qui reste indispensable à chaque opération est un coût, pas un service. Il valait mieux livrer un socle qu'ils s'approprient qu'une dépendance qui se facture.

Le chantier en cours ne concerne plus l'intégration mais la paie : un outil séparé qui lit les arrêts maladie dès leur arrivée, en extrait ce qu'il faut, et le transmet par une interface programmatique pour que le salaire soit calculé correctement. C'est le genre de brique qui n'a de sens qu'une fois le socle stable — sur une base bricolée, elle ne tiendrait pas.