Quand le fil d’actu tousse, on fait le ménage dans la cave
Cette semaine, le flux RSS tech ressemble à un match de Ligue 1 un mardi soir de novembre : personne ne marque, tout le monde fait tourner, et les commentateurs meublent avec des anecdotes sur la pelouse. Pas de nouveau modèle d’IA qui révolutionne l’humanité, pas d’acquisition à 40 milliards, pas de PDG qui se prend pour Steve Jobs sur scène. Bref, du calme plat.
Chez Smarsys, on adore ces semaines-là. Parce que c’est exactement le moment où on peut parler du sujet que personne n’ouvre en comité de direction : la dette technique de votre SI. Ce truc invisible qui coûte un bras, qui ralentit tout, et dont personne n’est responsable — exactement comme la vaisselle en coloc.
La dette technique, c’est quoi au juste ?
Imaginez que vous achetez une maison en 2010. Vous y bricolez un garage en 2013, une véranda en 2016, une piscine hors-sol en 2019, et une extension bureau en 2021 parce que confinement oblige. Chaque ajout a été fait vite, avec les matériaux du moment, par un artisan différent. Résultat en 2026 : les tuyaux ne sont pas aux normes, le compteur électrique explose quand vous branchez le four, et personne ne sait pourquoi la porte du garage s’ouvre toute seule le mardi.
Votre SI, c’est pareil. L’ERP a été installé en 2012. Le CRM greffé dessus en 2015. Un connecteur maison bricolé en 2017 par un stagiaire brillant mais parti depuis. Une couche BI posée en 2019 parce que le DAF voulait ses dashboards. Et en 2024, on a plugué une IA générative par-dessus pour « faire comme tout le monde ».
Les symptômes qui ne trompent pas
Vous reconnaissez votre entreprise si :
- Personne ne sait exactement combien de systèmes différents hébergent la donnée « client ».
- Le même chiffre d’affaires sort différent selon qu’on l’extrait de l’ERP, du CRM ou du tableau Excel de Jean-Michel.
- Chaque nouveau projet commence par six semaines d’archéologie pour comprendre « comment ça marche aujourd’hui ».
- Le prestataire historique est le seul à savoir où sont les mots de passe, et il part à la retraite en mars.
Pourquoi personne n’en parle en CoDir ?
Parce que la dette technique, c’est comme le cholestérol : indolore jusqu’au jour où ça fait très mal. Et surtout, c’est un sujet non glamour. Annoncer « on lance un projet IA générative pour transformer l’expérience client », ça fait un slide magnifique au board. Annoncer « on va passer six mois à refactorer l’intégration entre notre ERP et notre CRM », ça fait fuir même le stagiaire du marketing.
Pourtant, la deuxième action est souvent la condition préalable de la première. Vous ne pouvez pas faire tourner une IA sérieuse sur des données éparpillées dans quinze silos qui ne se parlent pas. Ou plutôt si, vous pouvez — mais les résultats auront la qualité d’une prédiction météo faite avec un baromètre cassé.
Le piège du « on verra plus tard »
Chaque décision court-terme — « on bricole un connecteur vite fait », « on duplique la base client pour aller plus vite », « on ajoute un champ custom plutôt que de refondre le modèle » — c’est un emprunt. Avec intérêts. Et le taux grimpe chaque année.
Au bout de dix ans, certaines PME se retrouvent avec un SI où 80% du budget IT part dans la maintenance du legacy, et seulement 20% pour l’innovation. C’est comme payer un loyer de 4000 CHF pour un studio à Renens : techniquement vous êtes logé, mais quelque chose cloche dans l’équation.
Comment attaquer le sujet sans tout casser ?
Bonne nouvelle : on ne vous demande pas de tout refaire. Un bon chantier de dette technique, c’est comme une rénovation énergétique — on priorise ce qui coûte le plus cher en invisible.
1. Cartographier avant de couper
Avant de toucher quoi que ce soit, on dessine. Quels systèmes hébergent quoi. Quels flux circulent entre eux. Qui est propriétaire de quelle donnée. Oui, c’est fastidieux. Non, vous n’y couperez pas. C’est l’équivalent du scan de la maison avant travaux.
2. Identifier les points de douleur business
Pas la peine de refactorer un module que personne n’utilise. On commence par là où ça fait mal : le processus de facturation qui plante une fois par mois, le reporting qui demande trois jours de retraitement manuel, le client qui doit répéter son nom trois fois parce que chaque service a sa fiche.
3. Choisir sa cible d’architecture
C’est là qu’arrive la question du cloud, du data lake, de la plateforme unifiée. Salesforce, AWS, Azure, Google Cloud, Microsoft 365, Infomaniak : chaque brique a ses forces. Le bon choix dépend de votre secteur, de vos contraintes réglementaires (nLPD oblige pour certaines données sensibles), de votre budget et de la maturité de vos équipes. Il n’y a pas de bonne réponse universelle — il y a une bonne réponse pour votre contexte.
4. Y aller par itérations
Un big bang de refonte, c’est le meilleur moyen de se planter. On découpe en chantiers de 3 à 6 mois, chacun avec un ROI mesurable. On livre, on apprend, on ajuste. C’est moins héroïque qu’un projet à 18 mois, mais ça a le mérite d’arriver au bout.
Le mot de la fin
Une semaine sans news, c’est une semaine où on peut enfin regarder sous le capot. Si votre DSI vous parle de dette technique depuis trois ans et que vous repoussez toujours « à après la prochaine release », c’est peut-être le moment de l’écouter. Parce que la prochaine release, elle arrivera plus vite si les fondations tiennent debout.
Et accessoirement : une IA bien nourrie, c’est une IA qui mange de la donnée propre. Pas un buffet froid de fichiers CSV périmés.
Sources
🤖 Comment cet article a été produit
Veille RSS automatisée, rédaction par Claude Opus 4.7 (API Anthropic), supervision éditoriale et brand voice par l'équipe Smarsys. Visuel généré par GPT Image 2 (OpenAI). Un pipeline maison construit sur Make.com + WordPress, similaire à ce que nous déployons pour nos clients. Envie du même setup chez vous ?