Automatisation des processus et systèmes de gestion internes pour PME

Ne remplacez pas votre ERP pour régler un problème de processus. Dans la plupart des PME, l’ERP ou le logiciel de comptabilité fait assez bien son travail de base ; les difficultés se situent dans les processus qui l’entourent : validations par e-mail, planification dans Excel, rapports assemblés à la main, données saisies deux fois. Utilisez l’automatisation des processus pour les flux de données entre les systèmes que vous gardez, et développez un petit outil interne pour le seul processus qu’aucun produit standard ne couvre. Ne remplacez un système central que s’il vous bloque réellement.

Tableur, low-code, module standard ou outil sur mesure ?

Chaque option a sa limite. Les tableurs lâchent dès que plusieurs personnes les modifient ou que leurs données doivent atteindre un autre système. Les connecteurs low-code peinent quand la logique se ramifie ou que les échecs doivent être gérés. Un module standard se transforme en contournements quand votre processus s’écarte du modèle de l’éditeur. Les outils sur mesure sont rentables pour les processus propres à votre activité, à condition que la première version reste modeste.

Option	Adapté pour	Atteint ses limites quand
Tableurs et e-mails	Un seul responsable, faible volume	Plusieurs personnes modifient, ou les données doivent atteindre d’autres systèmes
Connecteurs low-code (Zapier, Make, n8n)	Déclencheurs simples entre outils cloud	La logique se ramifie, le volume augmente, les échecs passent inaperçus
Module logiciel standard	Processus que votre éditeur d’ERP modélise déjà	Votre processus diffère et les contournements s’accumulent
Outil interne sur mesure et intégrations	Processus clés propres à votre activité	Le périmètre n’est pas maîtrisé ; commencez par un seul processus

Comment un système interne est-il construit ?

Nous commençons par le modèle de données : quels objets existent (intervention, commande, client, machine), quel système détient chacun d’eux, et qui peut voir ou modifier quoi. L’outil interne est une application web avec accès par rôle et journal d’audit, qui s’appuie sur PostgreSQL. Des tâches en arrière-plan exécutent les processus et se synchronisent avec l’ERP ou la comptabilité via son API, selon un calendrier ou sur événement. Chaque exécution est journalisée : une synchronisation ratée apparaît sur une liste d’erreurs, avec sa cause.

Deux habitudes tirées de nos propres projets s’appliquent aussi ici. Les règles métier (seuils, plages horaires, priorités) sont des paramètres, pas du code : vous pouvez les modifier sans nouvelle version du logiciel. Et les intégrations avec des systèmes qui ne vous appartiennent pas sont en lecture seule, sauf si l’écriture est nécessaire. Dans le système de réactivation d’affiliés construit pour un client SaaS, la connexion à la plateforme de suivi du client ne peut appeler qu’une liste autorisée d’opérations de lecture, et un test prouve qu’un import complet n’effectue aucun appel en écriture.

Exemple : une entreprise de technique du bâtiment avec 40 techniciens

Scénario illustratif, pas un projet client.

Une entreprise de chauffage et de sanitaire près de Zurich reçoit ses ordres d’intervention par téléphone et par e-mail. La planification se fait dans une feuille Excel, les techniciens remplissent des rapports d’intervention papier, et le bureau saisit les heures et le matériel dans Abacus pour la facturation, souvent une semaine plus tard.

La première version couvre un seul processus : le rapport d’intervention. Les techniciens voient leurs interventions sur leur téléphone, saisissent heures, matériel et photos sur place, et le client signe à l’écran. Une intervention terminée crée les données de facturation dans Abacus via son API REST. Les interventions non facturées et les commandes ouvertes apparaissent sur un tableau de bord. La phase deux sort la planification d’Excel pour l’intégrer au même outil ; la phase trois ajoute les contrats de maintenance, qui génèrent automatiquement les interventions de service.

Qu’en est-il de la protection des données et de l’hébergement ?

La loi fédérale sur la protection des données (LPD) révisée, en vigueur depuis le 1er septembre 2023, s’applique aux données traitées en Suisse et impose la protection des données dès la conception et par défaut (art. 7) ; le RGPD pose la même exigence pour les personnes dans l’UE (art. 25). Pour les systèmes internes, cela signifie accès par rôle, journal d’audit, règles de suppression, et un lieu d’hébergement choisi avant le développement, pas après.

Les outils internes stockent souvent des données sur le personnel, y compris les heures et les lieux d’intervention : nous documentons donc ce qui est stocké et pourquoi. Les entreprises de moins de 250 collaborateurs sont en général dispensées de tenir un registre des activités de traitement, sauf si elles traitent des données sensibles à grande échelle ou pratiquent un profilage à risque élevé.

Comment se déroule un projet ?

1. Découverte. Nous nous asseyons avec les personnes qui font le travail, cartographions le processus et comptons les étapes manuelles.
2. Architecture. Modèle de données, système de référence pour chaque type de données, rôles, intégrations, et périmètre de la première version.
3. Développement. Des itérations courtes, avec un environnement de test que votre équipe peut essayer tôt et souvent.
4. Lancement. D’abord une équipe ou un site, avec l’ancien processus disponible en solution de repli.
5. Itération. Retours des utilisateurs, puis le processus suivant sur la même base.

Après la phase de découverte, vous recevez une offre à prix forfaitaire ou par phases. La question plus large de savoir quels systèmes garder, connecter ou remplacer est traitée sur la page transformation digitale.