Quand il est temps de quitter les tableurs, comment calculer un budget, comment concevoir un modèle de données et comment basculer sans arrêter l'entreprise un mois. Un guide complet, de la première idée au premier mois en production.
La plupart des entreprises ne cherchent pas un système propre parce qu'elles veulent un nouveau logiciel. Elles cherchent parce que quelque chose s'est perdu deux fois, que quelqu'un a oublié de facturer, ou que personne ne sait dire ce qu'une mission a rapporté.
Ce guide parcourt tout le chemin, de cette première insatisfaction au premier mois en production. Chaque chapitre résume l'essentiel et renvoie à un texte détaillé.
1. Comment savoir qu'il est temps
Il y a quatre signaux plutôt fiables. Deux suffisent :
Le tableur a plus d'un éditeur. Dès que deux personnes écrivent dans le même fichier, la question « quelle version est à jour » commence. Ce problème ne se règle pas par la discipline.
Les données existent à plusieurs endroits et ne concordent pas. Le client est dans le CRM, sa mission dans l'outil de projets, les heures dans un tableur, la facture en comptabilité. Toute question qui franchit une frontière prend une demi-journée.
Quelque chose est passé à la trappe. Une facture oubliée, une échéance ratée, une promesse non tenue. Une fois c'est le hasard, deux fois c'est une faille systémique.
Le départ d'une personne ferait perdre la vue d'ensemble. Quand un processus vit dans une tête et non dans un système, c'est un risque qui grandit avec l'entreprise.
En détail : Quand un tableur ne suffit plus et Ce que coûtent des outils dispersés.
2. Pourquoi vous avez trois systèmes
Presque personne n'a choisi un stack dispersé. Il s'est accumulé : le CRM avec le deuxième commercial, l'outil de projets avec la première grosse réalisation, le tableur pour l'argent parce qu'aucun des deux ne savait calculer la marge.
Chacune de ces étapes était juste sur le moment. Le problème est la somme - et surtout le travail qui naît aux frontières. Ressaisie, recherche, rapprochement mensuel. Rien de tout cela ne figure sur une facture.
Personne ne l'a choisi. Cela s'est accumulé.
Chaque outil a résolu un problème et créé une frontière. Le travail qui naît sur ces frontières n'est visible nulle part.
En détail : CRM, ERP, outil de projets : trois systèmes qui ne se parlent pas.
3. Quatre voies et leurs coûts réels
Une fois la décision prise vient la question du prix. Il y a quatre voies :
| Voie | Prix d'entrée | Qui fait les changements | Risque principal |
|---|---|---|---|
| Logiciel standard | Bas | Personne (impossible) | Le processus plie devant l'outil |
| Développement sur mesure | Le plus élevé | Le prestataire | Dépendance au prestataire |
| Indépendant + IA | Moyen | Une personne | Dépendance à une personne |
| Plateforme no-code | Le plus bas | N'importe qui dans l'équipe | Dépendance à la plateforme |
L'essentiel est de ne pas regarder la première facture mais le total sur trois ans. Le prix d'entrée est celui qu'on vous annonce ; les années deux et trois décident.
Le budget doit aussi inclure des postes qui ne figurent jamais dans un devis : déploiement et formation, changements (pas « au cas où » mais une certitude), exploitation, et le risque de perdre la personne qui connaît le système.
En détail : Ce que coûte une application sur mesure en 2026.
4. La conception du modèle de données - la seule partie qu'on ne peut pas bâcler
C'est là que se décide si le système sera encore utilisable dans deux ans. Ce n'est pas un travail technique, c'est un travail sur votre processus.
Commencez par les entités. Notez les noms communs que vous utilisez : client, mission, devis, facture, technicien, relevé d'heures, document. Ce seront vos bases.
Déterminez les liens. Un client a plusieurs missions. Une mission a un devis et plusieurs relevés. Une facture appartient à une mission. Cette étape révèle l'essentiel des malentendus dans une équipe - il apparaît souvent que deux personnes entendaient deux choses différentes par « mission ».
Gardez le modèle plus petit que vous ne voulez. L'erreur classique est de concevoir quinze bases d'avance. Commencez par trois qui couvrent le flux principal et ajoutez selon le besoin avéré.
Testez-le par une question. Un bon modèle se reconnaît à ce que l'équipe peut en tirer l'étape suivante - émettre une facture, envoyer un procès-verbal, calculer une marge. Pas à ce qu'il ait toutes les colonnes.
En détail : Un modèle de données qui grandit avec l'équipe.
5. Qui voit quoi
Les droits sont souvent repoussés, et c'est une erreur - ils doivent tenir dans chaque vue, chaque export et chaque e-mail que le système envoie.
Trois questions suffisent à trancher en amont :
- Qui doit voir les champs sensibles (prix, marges, données personnelles) ?
- Qui doit seulement lire et qui doit aussi modifier ?
- Que doit-on, s'il y a lieu, rendre visible hors de l'entreprise ?
Les réponses se traduisent en une structure de rôles réglée une fois et valable partout. Distinguez deux choses : masquer une colonne régit « ce qu'il voit dans une fiche », restreindre l'accès à une base régit « à quelles fiches il accède ».
En détail : Droits d'accès et visibilité des données.
6. Basculer sans big bang
Personne ne peut éteindre trois systèmes un lundi. Une démarche éprouvée tient en trois phases :
Phase 1 - une frontière. Trouvez l'endroit qui fait le plus mal (généralement commercial ↔ réalisation ou réalisation ↔ argent) et construisez une base commune pour celui-là seul. Clients et missions au même endroit.
Phase 2 - ajouter ce qui va avec. Relevés d'heures, documents, correspondance. À ce stade, la plupart des entreprises constatent qu'elles n'ont plus besoin de la moitié de leurs tableurs.
Phase 3 - éteindre l'ancien. Pas avant quelques semaines de fonctionnement en parallèle. Marquez d'abord l'ancien tableur en lecture seule et archivez-le seulement ensuite.
Ce qu'il ne faut pas reprendre : tout l'historique. La dernière année suffit généralement, le reste encombre les vues.
En détail : Migrer depuis Excel ou Notion.
7. Les automatisations en dernier
Une tentation courante est d'activer les automatisations dès le premier jour. Mieux vaut attendre que le système tourne quelques semaines - c'est seulement alors que vous savez quelles étapes se répètent vraiment.
Les premières automatisations qui paient presque toujours :
- surveiller les missions terminées sans facture,
- un rappel quelques jours avant une échéance,
- une alerte sur les relevés d'heures manquants en fin de semaine,
- la création automatique d'une fiche depuis une demande entrante.
En détail : L'automatisation : introduction complète et Automatiser les processus d'entreprise.
8. Le premier mois en production
Ce à quoi s'attendre réellement :
Semaine 1. Les gens se plaignent que c'était plus rapide dans le tableur. C'est vrai - pour une personne. Tenez bon.
Semaines 2–3. Les premières demandes de modification arrivent. C'est bon signe, pas mauvais : cela veut dire qu'ils l'utilisent. Faites les changements au fil de l'eau et vite.
Semaine 4. Arrive le premier moment où quelqu'un trouve une réponse qu'il aurait cherchée une demi-heure avant. C'est généralement là que ça bascule.
Ce qu'il faut mesurer : pas la satisfaction, mais le fait qu'un tableur continue ou non d'apparaître à côté. Si oui, il manque quelque chose au système - et ce tableur est l'indication précise de quoi.
Questions fréquentes sur l'introduction d'un système d'entreprise
Combien de temps prend toute la bascule ?
La première frontière : des jours à deux semaines. La bascule complète pour vingt personnes : un à trois mois - non parce que la technique est lente, mais parce que les gens s'adaptent progressivement.
Qui devrait en être responsable en interne ?
Une ou deux personnes « administratrices de l'espace », typiquement quelqu'un de l'exploitation ou de l'administration qui comprend le processus. Pas nécessairement la plus technique - plutôt celle qui sait le mieux comment le travail se déroule réellement.
Et si nous avons mal conçu le modèle ?
Cela arrive presque toujours et c'est normal. Sur une plateforme no-code, champs, statuts et liens se modifient en production. Dans une application développée, changer le modèle est un travail de développeur - c'est précisément pourquoi cette propriété compte plus que n'importe quelle fonctionnalité.
Devons-nous abandonner le logiciel comptable ?
Non. La comptabilité a ses obligations légales et reste généralement où elle est. La consolidation a du sens pour les données opérationnelles : clients, missions, échéances, heures, documents.
Comment convaincre une équipe qui ne veut rien changer ?
Au mieux en faisant que la première chose réglée par le nouveau système soit quelque chose qui l'agace. Pas le reporting pour le dirigeant, mais la fin des recherches ou la fin de la ressaisie. Le reste suit tout seul.