En bref : La dette technique PME est le passif que crée chaque solution informatique posée à la hâte, faute de budget ou de mandat pour la faire correctement. Comme une dette financière, elle porte intérêt : chaque rustine ajoutée coûte du temps de maintien, ferme des options futures et se paie plus cher que si elle avait été réglée dès le départ.
Si vous dirigez une PME et que vos TI multiplient les urgences, ce guide explique le mécanisme derrière le mot. Pas pour blâmer qui répare, pour comprendre pourquoi il répare de cette façon.
Dans cet article
Qu’est-ce que la dette technique PME, expliquée à un dirigeant ?
La dette technique PME désigne l’écart entre l’état réel de vos systèmes informatiques et l’état où ils devraient être pour fonctionner de façon fiable et sécurisée. Chaque fois qu’une équipe choisit un correctif rapide plutôt qu’une solution durable, faute de temps ou de budget, cet écart grandit. Comme une dette financière, elle est parfois nécessaire à court terme. Le problème survient quand personne ne la rembourse.
Le parallèle financier n’est pas qu’une image. La dette technique fonctionne comme un passif hors bilan : elle n’apparaît nulle part dans vos états financiers, elle grossit en silence tant que personne ne la mesure, et elle se manifeste le jour où un système cède au pire moment possible.
Elle ne se limite pas au code ou aux serveurs :
- Politique de sécurité jamais mise à jour.
- Inventaire des accès qui ne correspond plus à qui travaille encore chez vous.
- Sauvegarde configurée il y a cinq ans et jamais testée depuis.
Le mot évoque l’informatique, le problème est de gouvernance.
Pourquoi mon équipe TI passe-t-elle son temps à éteindre des feux ?
Parce que le mandat qu’on lui donne, dans les faits, c’est d’éteindre des feux. Une équipe TI sous-financée n’a ni le temps ni le budget pour retirer les rustines qu’elle a posées, seulement celui pour en poser une nouvelle avant que la précédente cède.
Nous documentons ce mécanisme en détail dans Le sous-financement des TI : ce que votre équipe n’ose pas vous dire : le sous-financement s’annonce presque jamais comme tel dans une réunion budgétaire. Il se vit plutôt comme un manque de temps chronique, année après année, jusqu’à devenir la normale.
Le duct tape informatique n’est pas un choix de carrière, c’est un choix imposé. Face à un système qui tombe un vendredi après-midi, une équipe compétente a deux options : le réparer avec ce qu’elle a sous la main, ou laisser l’entreprise sans service jusqu’à ce qu’un budget existe pour la vraie solution. Choisir de réparer, c’est choisir l’entreprise. Ce n’est pas un raccourci paresseux, c’est un arbitrage fait sous pression, avec les moyens qu’on a.
Le cercle se referme de lui-même. Le temps consacré à réparer est du temps qui ne sert pas à documenter, à planifier ou à retirer les rustines précédentes. Plus le cycle dure, moins il reste de marge pour en sortir sans aide extérieure.
Le rafistolage informatique est-il un signe d’incompétence ?
Non. C’est souvent l’inverse. Garder en fonction un système vieillissant, sans budget de remplacement et sans documentation à jour, en anticipant les pannes avant qu’elles arrivent, demande davantage de compétence et de vigilance que d’installer un système neuf dans des conditions idéales.
Le risque n’est pas dans la compétence de l’équipe qui rafistole. Il est dans ce que le rafistolage laisse derrière lui : une connaissance concentrée dans quelques têtes plutôt que dans une documentation, un système que plus personne n’ose toucher de peur de déclencher une panne en cascade, une continuité d’affaires qui tient parce qu’une ou deux personnes savent exactement où appuyer.
Le jour où cette personne est en vacances, malade ou change d’emploi, le risque cesse d’être théorique. Ce n’est pas un scénario rare : c’est l’issue prévisible de tout système dont la mémoire vit dans une tête plutôt que dans un document.
Il y a une distinction à faire, et elle change tout dans la façon d’évaluer une équipe. Une équipe qui rafistole sans jamais rien signaler à la direction cache un problème. Une équipe qui rafistole en le disant clairement, en documentant ce qu’elle bricole et pourquoi, en réclamant les moyens de faire autrement, fait exactement son travail dans les conditions qu’on lui a données. La seconde mérite d’être écoutée, pas jugée.
Combien coûte réellement une solution temporaire ?
La réponse honnête : plus que son coût affiché, et le calcul se fait rarement au moment de la décision. Une rustine a un coût immédiat visible, souvent minime. Elle a aussi des coûts différés qui ne paraissent sur aucune facture :
- Heures que l’équipe consacre chaque mois à maintenir un système qu’elle n’a jamais eu le temps de refaire.
- Projets reportés parce que le temps disponible sert à empêcher l’ancien système de tomber.
- Options qui se ferment quand un système devient trop fragile pour qu’on ose y greffer quoi que ce soit de nouveau.
C’est le mécanisme des intérêts composés appliqué à l’informatique. Une rustine seule coûte peu. Dix rustines empilées sur le même système, posées par des personnes différentes à des moments différents, sans qu’aucune ne soit jamais retirée, ne coûtent pas dix fois plus cher : elles coûtent davantage, parce que chaque nouvelle rustine doit composer avec toutes celles qui existent déjà, et que personne ne comprend plus l’ensemble.
Il y a aussi un coût que les dirigeants québécois découvrent souvent trop tard. Un système rafistolé au fil des années est rarement documenté au niveau qu’exige la Loi 25 pour les renseignements personnels qu’il traite : qui y a accès, où les données résident, combien de temps elles sont conservées. Ce n’est pas un problème tant qu’il n’y a pas d’incident. C’est un problème précisément le jour où il y en a un, au moment où on vous demandera de démontrer ce que vous ne pouvez pas démontrer.
Une statistique précise sur la part du temps d’une équipe TI absorbée par le simple maintien plutôt que par des projets serait utile ici. Nous préférons ne pas en avancer une sans source vérifiée : le constat qualitatif suffit à orienter la décision, et un audit chiffre l’écart réel pour votre entreprise plutôt qu’une moyenne générique.
Comment reconnaître la dette technique dans votre entreprise ?
La dette technique PME ne s’annonce pas par un avis officiel. Elle se reconnaît à des symptômes que la plupart des dirigeants ont déjà observés sans les nommer ainsi.
| Ce que vous voyez | Ce que ça cache généralement |
|---|---|
| Un correctif posé « en attendant » qui devient permanent | Une décision reportée faute de budget ou de mandat clair |
| Une seule personne sait comment redémarrer tel système | Une continuité d’affaires qui dépend d’une mémoire, pas d’une documentation |
| Chaque mise à jour prend plus de temps que la précédente | Des couches de rustines empilées sans qu’aucune ne soit retirée |
| Un projet TI toujours repoussé au trimestre suivant | Un temps d’équipe déjà absorbé par le maintien des systèmes existants |
| Une hésitation à toucher à un système qui « fonctionne » | La crainte qu’une modification déclenche une panne en cascade |
Aucun de ces signes, pris seul, ne veut dire que votre entreprise est en danger imminent. Ensemble, répétés sur plusieurs systèmes, ils dessinent un portrait qu’il vaut la peine de faire mesurer par quelqu’un qui n’a pas posé les rustines lui-même. Un regard interne, aussi honnête soit-il, a du mal à juger objectivement le travail qu’il a produit sous pression.
Le Centre canadien pour la cybersécurité publie des guides destinés spécifiquement aux PME sur les pratiques de sécurité de base et la gestion des risques informatiques. Ils valent le détour si vous voulez creuser la question au-delà de ce texte, en particulier pour situer votre entreprise face aux pratiques de base recommandées à l’échelle canadienne.
Que faire pour sortir du cycle du rafistolage ?
Trois gestes, dans l’ordre, plutôt que trois solutions miracles.
- Faites mesurer l’écart avant de le juger. Un audit informatique indépendant ne blâme personne : il documente ce qui existe réellement, système par système, et le risque que ça pose pour l’entreprise.
- Priorisez par risque, pas par âge du système. Un vieux système stable et bien compris inquiète souvent moins qu’un système récent que plus personne ne maîtrise entièrement.
- Donnez à votre équipe un mandat explicite pour rembourser la dette, pas seulement pour la gérer au jour le jour. Sans temps dédié à retirer les rustines, elles s’empilent indéfiniment, peu importe la compétence de qui les pose.
Notre guide complet sur l’audit informatique détaille comment se déroule cette démarche, de la première rencontre jusqu’au rapport final. La dette technique PME n’y est pas traitée comme une faute à corriger chez votre équipe, mais comme un risque d’affaires à chiffrer et à prioriser, au même titre qu’un risque financier ou juridique.
Avant de juger le duct tape, mesurez ce qu’il retient. Un diagnostic TI indépendant chiffre et priorise le risque accumulé dans vos systèmes, et donne à votre équipe les moyens de faire autrement que de rafistoler sous pression.
Pour aller plus loin avec Factero :
- un audit TI indépendant de votre parc
- bâtir une feuille de route TI priorisée
- direction TI à temps partiel (vCIO)
Foire aux questions
La dette technique PME touche-t-elle seulement les grandes entreprises ?
Non, c’est l’inverse qui est vrai le plus souvent. Une grande entreprise a généralement les moyens de remplacer un système avant qu’il devienne critique. Une PME, qui gère ses TI avec une équipe restreinte et un budget serré, accumule la dette technique aussi vite, sinon plus vite, et la voit plus tard, faute de ressources pour la surveiller de près.
Qui est responsable de la dette technique : l’équipe TI ou la direction ?
Rarement l’équipe, au sens d’une faute. Elle rafistole parce que c’est l’option qui reste quand le budget ou le mandat pour agir autrement n’existe pas. La question utile n’est pas qui a posé la rustine, mais qui a décidé, en amont, de ne pas financer la solution durable. Cette décision revient à la direction, pas à l’équipe qui exécute sous pression.
Faut-il tester régulièrement ses sauvegardes informatiques ?
Oui, une sauvegarde jamais testée est une hypothèse, pas une protection. C’est l’exemple même de dette technique le plus fréquent : configurée une fois, jamais vérifiée depuis, elle promet une restauration qui n’a jamais été mise à l’épreuve. Tester coûte quelques heures. Découvrir qu’elle ne fonctionne pas se fait généralement au pire moment, pendant l’incident qui la rendait nécessaire.
Quels sont les risques concrets de garder des systèmes informatiques dépassés ?
Trois risques reviennent le plus souvent. Le support technique devient difficile à trouver ou coûteux quand un fournisseur cesse de maintenir son produit. Les vulnérabilités de sécurité s’accumulent faute de correctifs disponibles. Et le système devient trop fragile pour qu’on ose y greffer quoi que ce soit de neuf. Un audit informatique indépendant mesure lequel de ces risques pèse le plus lourd dans votre cas, avant qu’un incident ne le fasse à votre place.
