Dette technique
Dette technique : ce qu’elle coûte à votre entreprise et pourquoi elle bloque l’IA
Votre équipe ou votre prestataire parle peut-être de « dette technique ». Vous, vous voyez des délais qui s’allongent et des factures qui montent. Le mot vient de Ward Cunningham. Il écrivait dès 1992 que livrer un premier code revient à s’endetter : un peu de dette fait gagner du temps, à condition de la rembourser vite (Cunningham, OOPSLA 1992).
Ce texte s’adresse au dirigeant d’une PME installée qui veut mettre de l’IA dans son entreprise.
Qu’est-ce que la dette technique, en mots de dirigeant ?
La dette technique désigne ce qui, dans un site ou un logiciel, a été fait vite et ralentit la suite. Sur un site marchand, c’est par exemple le calcul des frais de port recopié à trois endroits, qu’il faut corriger trois fois, ou un module de paiement resté sur une version que son éditeur ne suit plus. Chaque raccourci a eu sa raison sur le moment, souvent une échéance commerciale. Le problème commence quand personne ne revient dessus, parce que cette dette porte intérêt.
Martin Fowler, l’un des auteurs de référence du génie logiciel, décrit la mécanique en deux temps. L’effort supplémentaire qu’il faut fournir pour ajouter une fonction à un code encombré, ce sont les intérêts. Le temps qu’il faudrait pour remettre ce code en ordre, c’est le principal (Martin Fowler, Technical Debt). Tant que le principal reste dû, chaque projet paie les intérêts. Votre équipe avance alors moins vite d’année en année, sans avoir changé de méthode.
Les points clés à retenir :
- Principal : le travail nécessaire pour remettre le code en ordre.
- Intérêts : le temps perdu à chaque évolution tant que ce travail n’est pas fait.
- Symptôme : les délais s’allongent alors que l’équipe reste la même.
- Risque : une version qui n’est plus maintenue ne reçoit plus de correctifs de sécurité.
- Remède : un remboursement planifié par ordre de risque, avec le site qui continue de vendre pendant les travaux.
Combien coûte la dette technique à une entreprise ?
En 2018, Stripe et l’institut Harris Poll ont interrogé plus de 1 000 développeurs et 1 000 dirigeants dans cinq pays, dont la France. Les développeurs y estimaient passer 13,5 heures par semaine sur la dette technique, pour une semaine de 41,1 heures (The Developer Coefficient, Stripe, 2018). En France, la maintenance au sens large montait à 20,9 heures sur 39,6, la moyenne la plus haute des cinq pays.
Rapporté à votre équipe, le calcul tient en une ligne. Si la moitié des heures que vous payez à vos développeurs ou à votre prestataire part dans l’entretien de l’existant, une facture sur deux sert à rester sur place. Ce coût se retrouve dans chaque devis d’évolution, sans ligne qui le nomme.
| Forme du coût | Comment elle se voit | Qui la paie |
|---|---|---|
| Intérêts | Chaque évolution prend plus de temps que prévu | Votre budget de développement |
| Pannes | Une correction casse une autre page | Vos clients, puis votre service client |
| Sécurité | Une version sans correctifs reste en ligne | Toute l’entreprise, le jour d’une faille |
| Dépendance | Une seule personne sait mettre en ligne | Votre continuité, le jour où elle part |
Comment repérer le problème sans lire une ligne de code ?
Cinq questions à votre équipe ou à votre prestataire suffisent pour une première lecture. Notez les réponses telles qu’elles viennent, sans les discuter :
- Délai : combien de temps sépare une demande simple, un texte ou un champ de formulaire, de sa mise en ligne ? Une réponse qui se compte en semaines signale une mise en ligne trop lourde.
- Mise en ligne : combien de personnes savent mettre le site en ligne ? Une seule, et votre activité dépend de ses vacances.
- Corrections : une correction casse-t-elle souvent autre chose ? Si oui, aucun test automatique ne vérifie les parcours qui comptent.
L’un de nous l’a vécu sur l’espace client de son agence web, un outil qu’il développe lui-même. En août 2026, un correctif d’affichage sur téléphone est parti en ligne sans qu’on revérifie le cas de la correction précédente. Pendant trois jours, l’onglet de messagerie est resté hors de l’écran. C’est un client qui l’a signalé : ses 84 messages étaient intacts, il ne pouvait plus les ouvrir. Un test automatique sur le plus petit écran l’aurait arrêté avant la mise en ligne.
- Versions : quelle version de la plateforme et du langage tourne aujourd’hui ? Comparez-la à la page de support de l’éditeur.
- Sauvegardes : quand une sauvegarde a-t-elle été restaurée pour la dernière fois ? Tant qu’elle n’a pas été restaurée, rien ne prouve qu’elle contient votre site.
Des réponses floues ou contradictoires sont déjà un résultat : elles montrent où la connaissance du système tient à une seule personne.
Pourquoi l’IA aggrave un code sans tests ni mise en ligne fiable ?
Un assistant IA écrit du code bien plus vite qu’un développeur. Ce gain ne tient que si chaque parcours du site est vérifié automatiquement. Sans cette vérification, l’assistant ajoute des pages de code dont personne ne contrôle les effets sur le reste du site, et les pannes partent en ligne avec elles.
Les mesures publiques vont dans ce sens. GitClear, éditeur d’un outil d’analyse de code, a mesuré 211 millions de lignes modifiées entre 2020 et 2024, chez Google, Microsoft, Meta et des entreprises privées. La part de lignes dupliquées est passée de 8,3 % en 2021 à 12,3 % en 2024 (GitClear, 2025). Le programme de recherche DORA de Google Cloud observe la même tension. Dans son rapport 2024, quand l’adoption de l’IA augmente, les équipes livrent un peu moins souvent, et leurs mises en ligne cassent plus souvent : leur stabilité recule de 7,2 % (Google Cloud, DORA 2024).
Selon l’Insee, en 2024, 9 % des entreprises de 10 à 49 salariés utilisaient au moins une technologie d’IA, contre 13 % en moyenne dans l’Union européenne (Insee Première n° 2061, juillet 2025).
Que risque un site e-commerce resté sur une ancienne version ?
Prenons une boutique lancée sur PrestaShop 1.6. La documentation officielle de PrestaShop indique que la branche 1.6.1 fonctionne au plus avec la version 7.1 de PHP, le langage sur lequel tourne PrestaShop (PrestaShop, exigences techniques). Or PHP 7.1 ne reçoit plus aucun correctif depuis le 1er décembre 2019, selon le calendrier publié par le projet PHP (php.net, versions en fin de vie). Cette boutique tourne donc sur un langage sans correctif de sécurité depuis près de sept ans.
Les versions plus récentes demandent la même vigilance. La documentation de PrestaShop 8 fixe PHP 8.1 comme version maximale (PrestaShop 8, exigences techniques), et PHP 8.1 ne reçoit plus de correctifs depuis le 31 décembre 2025 (php.net). La sortie existe : PrestaShop 9 accepte PHP 8.1 à 8.5 (PrestaShop 9, exigences techniques). Quand un logiciel arrive en fin de vie, Cybermalveillance.gouv.fr, le dispositif national d’assistance aux victimes, conseille d’identifier les délais et les ressources nécessaires pour migrer (Cybermalveillance.gouv.fr, les mises à jour).
Pour un dirigeant, la première question porte donc sur la version qui tourne et sur sa date de fin de support. La refonte vient ensuite, si le chiffrage la justifie : une migration bien préparée garde vos fiches produits, vos clients et votre référencement.
Par où commencer pour rembourser la dette technique ?
Rembourser la dette technique ne demande pas de tout réécrire. Une réécriture complète remplace une dette connue par une dette nouvelle, et arrête souvent les évolutions pendant des mois. L’ordre qui protège le chiffre d’affaires part du risque le plus grave et avance chantier par chantier, avec le site qui reste en ligne.
| Chantier | Pourquoi d’abord | Signe que c’est fait |
|---|---|---|
| Inventaire des versions et des accès | On ne protège pas ce qu’on ne connaît pas | Une page liste plateforme, versions, hébergement et accès |
| Sauvegarde restaurée | Sans restauration, personne ne sait si elle est complète | Une restauration complète a réussi, datée |
| Mise en ligne écrite et répétable | Le site ne dépend plus d’une seule personne | Deux personnes au moins mettent en ligne avec la même procédure |
| Tests des parcours qui rapportent | Les pannes se voient avant vos clients | Panier, paiement, devis et formulaire testés à chaque modification |
| Mises à jour de sécurité | Les failles connues se referment | Plateforme et langage dans une version maintenue |
| Agents IA et automatisations | Le site détecte désormais ses pannes | L’équipe livre plus souvent sans casser davantage |
Chaque ligne se chiffre séparément, en jours de travail, ce qui permet d’étaler la dépense sur plusieurs trimestres. Les deux premières lignes coûtent peu et réduisent déjà le risque le plus lourd, celui de perdre le site.
Comment nous menons un audit avant de brancher l’IA
Kyy 42 commence par un audit en trois volets : le code, les pratiques de l’équipe et la mise en ligne. L’audit débouche sur un plan d’action en chantiers classés par priorité, que votre équipe mène seule ou avec nous. Nous formons ensuite vos développeurs à travailler avec un assistant IA sur un site dont chaque parcours est vérifié automatiquement, pour que le temps gagné ne reparte pas en corrections.
La démarche complète est décrite dans l’approche de Kyy 42. Les automatisations que nous installons une fois le socle sain, de la boîte mail à la facturation, sont présentées dans les solutions.
Ce que vous pouvez demander dès lundi
Avec les réponses à ces cinq questions, un audit peut chiffrer le principal de votre dette et proposer l’ordre de remboursement. C’est l’objet de la visio de 30 minutes que nous proposons : vous décrivez votre site ou votre logiciel, nous vous disons par quoi un audit commencerait.
Questions fréquentes
La dette technique est-elle une faute de l’équipe ?
La dette technique est souvent un choix assumé : livrer vite pour tenir une date, en sachant qu’il faudra reprendre le travail. Martin Fowler distingue d’ailleurs la dette prudente, prise en pesant son coût, de la dette imprudente, prise par négligence ou par méconnaissance (Technical Debt Quadrant). La faute commence quand personne ne planifie le remboursement.
Combien coûte un audit de dette technique ?
Le prix dépend de la taille du site et du nombre d’outils reliés. Nous le fixons après une visio de 30 minutes, avant tout engagement.
Qui doit réaliser l’audit : notre prestataire actuel ou un tiers ?
Un regard extérieur voit ce que l’équipe en place ne voit plus, et il n’a pas de code à défendre. Votre prestataire reste le mieux placé pour corriger ensuite.
Un petit site e-commerce est-il concerné ?
Une boutique de quelques centaines de produits a moins de code, et sa dette tient souvent à des versions anciennes et à des modules plus maintenus. Le risque principal y tient alors à la sécurité plus qu’à la lenteur des évolutions. L’inventaire des versions suffit souvent à décider d’une mise à jour ou d’une migration. Les autres questions des dirigeants sont rassemblées dans la FAQ de Kyy 42.
Comment savoir si un prestataire laisse de la dette ?
Demandez-lui comment il met en ligne, quels parcours sont testés automatiquement et quelle version de la plateforme il installe. Un prestataire sérieux répond avec une procédure écrite et une liste de tests. Une réponse du type « on vérifie à la main » vous dit que la dette s’accumule à chaque livraison.