Qu'est-ce que la dette technique ? Comment la mesurer et que faire ?
La dette technique est le coût caché des raccourcis pris lors du développement logiciel — et elle s'accumule à l'instar d'une dette financière. Voici comment la reconnaître, la mesurer et prendre une décision éclairée quant à son remboursement.
Chaque équipe logicielle avec laquelle nous avons travaillé porte une certaine dette technique. La plupart d'entre elles en sont conscientes. Beaucoup ont appris à vivre avec. Un petit nombre en est silencieusement détruit.
La dette technique est l'un de ces concepts qui se situe à l'intersection de l'ingénierie et des enjeux métier d'une manière qui rend la discussion claire particulièrement difficile. Les ingénieurs l'utilisent comme raccourci pour désigner tout ce qui est désordonné dans la base de code. Les chefs de produit l'entendent comme une demande de temps qu'ils ne peuvent pas accorder. Les fondateurs non techniques n'en ont souvent aucune représentation mentale — jusqu'au jour où une simple demande de fonctionnalité prend trois mois à livrer et où personne ne peut l'expliquer de manière satisfaisante.
La métaphore de la dette financière est pertinente, et nous y reviendrons tout au long de cet article. L'idée essentielle est la suivante : chaque raccourci pris lors du développement logiciel crée un passif. Ce passif ne disparaît pas. Il demeure dans la base de code, accumulant silencieusement des intérêts — ralentissant chaque modification future, introduisant de la fragilité, rendant le système plus difficile à comprendre. À un moment donné, le remboursement des intérêts devient le coût dominant du fonctionnement de l'équipe d'ingénierie. À un moment donné, le capital devient si important que l'équipe est à peine fonctionnelle.
L'objectif de ce guide est de vous donner une image complète et pratique de la dette technique : ce qu'elle est, d'où elle vient, comment la mesurer et comment prendre des décisions rationnelles quant à ce qu'il convient d'en faire.
Qu'est-ce que la dette technique ?
Le terme a été inventé par Ward Cunningham en 1992, à l'origine pour expliquer pourquoi les logiciels deviennent de plus en plus difficiles à modifier avec le temps. Son analogie était délibérée : tout comme la dette financière vous permet d'acquérir quelque chose maintenant et d'en payer le coût plus tard, la dette technique permet à une équipe logicielle de livrer des fonctionnalités plus rapidement en acceptant une qualité d'implémentation inférieure — pour en payer le coût ultérieurement, à chaque fois que ce code doit être modifié, étendu ou corrigé.
La formulation originale de Cunningham était en réalité nuancée d'une manière que l'usage courant tend souvent à aplanir. Il décrivait un scénario spécifique : livrer du code qui fonctionne mais qui n'est pas encore pleinement compris, avec l'intention d'y revenir pour le remanier une fois que l'on en sait davantage. Il s'agit d'un compromis légitime, voire intelligent. La dette est délibérée et l'équipe en est consciente.
La taxonomie plus large de la dette technique a été formalisée par Martin Fowler dans ce que l'on appelle souvent le Quadrant de la dette technique, qui cartographie la dette selon deux axes : si elle a été contractée délibérément ou par inadvertance, et si la décision était imprudente ou réfléchie.
Imprudente et délibérée : L'équipe connaît la bonne approche et choisit consciemment de l'ignorer. « Nous n'avons pas le temps d'écrire des tests. » « Nous allons simplement coder cette valeur en dur pour l'instant. » C'est le type de dette qui cause le plus de dommages à long terme et qui résulte le plus souvent d'une pression de livraison à court terme primant sur le jugement d'ingénierie.
Imprudente et involontaire : L'équipe prend une mauvaise décision sans réaliser qu'il s'agit d'une mauvaise décision. Résultat fréquent du manque d'expérience, de la méconnaissance du domaine ou de l'ignorance de meilleures pratiques. « Vous voulez dire qu'il existe une méthode standard pour gérer cela ? Nous avons construit la nôtre. » La dette est réelle, mais n'était pas un compromis conscient — c'était simplement une erreur commise de bonne foi.
Réfléchie et délibérée : L'équipe connaît la bonne approche mais choisit une voie plus rapide avec l'intention claire d'y revenir et de l'améliorer ultérieurement. C'est le cas original de Cunningham. Il s'agit d'une décision commerciale légitime lorsqu'elle est prise avec soin et correctement suivie. La dette devient un problème si le « plus tard » n'arrive jamais.
Réfléchie et involontaire : L'équipe a pris la meilleure décision possible avec les informations dont elle disposait à l'époque. Par la suite, elle a appris quelque chose — sur le domaine, sur de meilleures pratiques, sur les exigences réelles du produit — qui a révélé que l'approche antérieure était sous-optimale. Il ne s'agit pas d'un échec. C'est ainsi que fonctionne le développement logiciel. La bonne réponse est de le reconnaître et de planifier pour y remédier.
Comprendre dans quel quadrant se situe votre dette est important, car cela détermine la façon dont vous en parlez, qui en est responsable et ce que son traitement implique.
Comment la dette technique s'accumule
La dette technique n'arrive généralement pas d'un seul coup. Elle s'accumule par couches, chacune individuellement justifiable, collectivement débilitante.
La pression de livraison est la cause la plus fréquente. Lorsqu'un lancement de produit, une échéance client ou une démonstration pour des investisseurs approche, les standards d'ingénierie sont les premiers à en pâtir. La couverture de tests diminue. La revue de code devient superficielle. Des décisions architecturales qui auraient mérité une semaine de réflexion sont prises en une après-midi. Aucun de ces raccourcis ne semble conséquent sur le moment. Sur un an, ils s'accumulent.
Les décisions « nous réglerons ça plus tard » qui ne sont jamais revisitées. C'est le cas classique. La solution de contournement temporaire qui devient une infrastructure permanente. La valeur de configuration codée en dur qui est copiée en trois autres endroits avant que quiconque pense à la centraliser. Le commentaire TODO qui vit dans la base de code depuis quatre ans.
Absence de revue de code, ou revue de code de mauvaise qualité. La revue de code est le mécanisme principal par lequel une équipe maintient et améliore ses standards partagés. Lorsqu'elle est omise sous pression, ou traitée comme une simple formalité plutôt que comme une véritable conversation technique, la base de code s'éloigne progressivement de tout standard cohérent.
Dépendances obsolètes. Les bibliothèques et les frameworks ne vieillissent pas bien. Des vulnérabilités de sécurité sont découvertes. Des améliorations de performance sont apportées dans les versions récentes. Les API changent. Une base de code qui n'a pas maintenu ses dépendances à jour accumule un risque spécifique qui finit par devenir urgent lorsqu'une CVE affecte un package critique.
Manque de tests. Il s'agit à la fois d'une cause et d'un amplificateur de la dette technique. Le code non testé est plus difficile à modifier en toute sécurité, ce qui signifie que les modifications prennent plus de temps et comportent plus de risques, ce qui pousse les développeurs à se précipiter davantage et à prendre plus de raccourcis, ce qui génère davantage de dette technique. La dette de tests se cumule sur elle-même.
Manque de documentation. Un code que personne n'a documenté — au niveau architectural, au niveau des interfaces API et au niveau de la logique complexe — ne peut être maintenu que par la personne qui l'a écrit. Lorsque cette personne part, la connaissance part avec elle.
Rotation des développeurs. Lorsqu'un développeur qui comprend bien un système part, ses connaissances institutionnelles ne se transfèrent pas automatiquement. Ce qui reste est un code qui fonctionne mais n'est pas compris, et la compréhension est le prérequis à toute modification. Chaque départ, sans transfert de connaissances approprié, augmente l'opacité du système.
Les signes que votre base de code souffre d'une dette technique
Vous n'avez peut-être pas encore réalisé d'audit formel de la dette, mais les symptômes suivants sont des indicateurs fiables que le problème est significatif.
Les fonctionnalités prennent un temps disproportionné à développer. Lorsqu'une modification qui devrait prendre deux jours en prend deux semaines, la raison la plus fréquente est que le code existant est si fragile, si mal compris ou si fortement couplé qu'une modification localisée nécessite de naviguer sur une large surface de risque.
Chaque modification casse autre chose. C'est souvent appelé la chirurgie à la chevrotine — le code est si étroitement couplé que modifier une chose provoque des défaillances inattendues ailleurs. Lorsque les développeurs ont peur de toucher certaines parties du système, cette peur est une donnée significative.
Les nouveaux développeurs ne parviennent pas à être productifs. Une base de code saine a une courbe d'apprentissage, mais un développeur senior devrait apporter des contributions significatives dans les premières semaines suivant son arrivée. Lorsque le processus d'intégration implique des mois d'apprentissage de connaissances tribales non documentées, ou lorsque les nouveaux membres de l'équipe sont explicitement mis en garde contre certaines parties du code, le système présente un problème structurel.
Vulnérabilités de sécurité dans les anciennes dépendances. Si un audit de dépendances révèle des packages présentant des CVE connues qui n'ont pas été mises à jour, l'équipe porte un risque qui finira par devenir un incident. C'est particulièrement courant dans les bases de code Node.js, Python et PHP plus anciennes, où le développeur d'origine n'est plus là pour gérer les mises à niveau.
Absence de couverture de tests significative. Lorsqu'il n'y a pas de tests, ou que les tests sont si superficiels qu'ils réussissent indépendamment du bon fonctionnement du code, chaque déploiement est un risque calculé. Les équipes dans cette situation développent souvent un gel informel des modifications des parties sensibles du système.
La base de code est redoutée plutôt que comprise. C'est l'indicateur le plus révélateur de tous. Lorsque des ingénieurs décrivent des parties de leur propre système comme « la partie effrayante » ou « la boîte noire que personne ne touche », la dette technique est déjà devenue une contrainte organisationnelle.
Comment mesurer la dette technique
On ne peut pas gérer ce que l'on ne peut pas mesurer. La dette technique est notoirement difficile à quantifier avec précision, mais il existe un ensemble de métriques et de proxies qui donnent une image utile et exploitable.
Métriques de qualité du code. Les outils d'analyse statique peuvent révéler plusieurs signaux quantitatifs : la complexité cyclomatique (le nombre de chemins indépendants dans une fonction — une complexité élevée signifie difficile à tester et à modifier), la duplication de code (logique copiée-collée qui doit être modifiée en plusieurs endroits lorsque les exigences évoluent) et la couverture de code (quel pourcentage de la base de code est exercé par des tests automatisés). Aucune de ces métriques ne raconte l'histoire complète à elle seule, mais ensemble elles créent une référence que vous pouvez suivre dans le temps.
Outils d'analyse statique. Des outils comme SonarQube et Code Climate agrègent ces métriques dans une interface unique et fournissent une estimation de la dette — généralement exprimée en temps de correction. SonarQube, par exemple, vous indiquera que votre base de code comporte environ 47 jours de travail de remédiation en attente, ventilés par catégorie. Ces estimations sont imprécises, mais elles fournissent une vue directionnelle et un moyen cohérent de suivre les progrès.
Audit d'ancienneté des dépendances. Exécutez un audit sur votre manifeste de packages — npm audit, pip-audit, bundle-audit selon votre stack — et examinez quels packages sont obsolètes, dans quelle mesure, et si certains présentent des avis de sécurité connus. Il s'agit d'un instantané concret et exploitable qui peut être produit en quelques minutes.
Le temps d'intégration comme métrique proxy. Demandez à votre équipe : combien de temps a-t-il réellement fallu au dernier nouveau développeur pour effectuer sa première contribution significative ? Si la réponse dépasse quatre à six semaines pour un développeur senior, la base de code n'est pas bien structurée ou bien documentée. Il s'agit d'une mesure qualitative, mais étonnamment fiable.
Le facteur bus. Le facteur bus (parfois euphémisé en « facteur loterie ») pose la question : combien de personnes devraient être touchées par un bus avant qu'une partie critique du système devienne impossible à maintenir ? Un facteur bus de un — une seule personne qui comprend de manière unique un composant — représente un risque concentré. Lorsque cette personne part, ce qui arrivera inévitablement, l'équipe perd des connaissances irremplaçables. Identifier les composants avec un facteur bus de un est une partie importante d'un audit de dette.
Types de dette technique et leur impact
Toute dette technique n'est pas égale. Le type de dette détermine le coût de son maintien et le coût de sa correction.
La dette architecturale est la plus coûteuse. Elle s'accumule lorsque la structure fondamentale du système — la façon dont les composants communiquent, la façon dont les données circulent, la façon dont le système est divisé en couches — est mal conçue ou est devenue obsolète à mesure que le produit a évolué. La dette architecturale ne peut pas être corrigée par le remaniement d'une fonction. Elle nécessite de restructurer de grandes parties du système, et ce travail est risqué et chronophage. Le coût de son maintien se cumule : chaque fonctionnalité construite sur une architecture déficiente est plus difficile à développer et porte sa propre dette locale.
La dette au niveau du code est la plus visible. Logique dupliquée, variables mal nommées, fonctions qui font trop de choses, patterns incohérents dans une base de code. Elle ralentit les développeurs de manière incrémentale à chaque modification et peut généralement être traitée progressivement sans perturbation majeure.
La dette de tests est dangereuse car elle masque d'autres dettes. Sans tests, vous ne pouvez pas savoir avec certitude si une modification a introduit une régression. La dette de tests rend chaque autre type de dette plus difficile à rembourser, car le remaniement en toute sécurité nécessite un harnais de tests.
La dette de documentation est facile à ignorer et coûteuse à négliger. Le coût est payé à chaque fois qu'un nouveau développeur rejoint l'équipe, à chaque fois qu'un développeur actuel revient sur une partie du code qu'il ne connaît pas, et à chaque fois qu'une partie prenante métier a besoin de comprendre le fonctionnement de quelque chose pour prendre une décision produit.
La dette d'infrastructure s'accumule lorsque les configurations cloud sont gérées manuellement plutôt que par le code, lorsque les environnements sont incohérents, lorsque les processus de déploiement sont manuels et non formalisés. Le standard moderne est l'Infrastructure as Code — Terraform, Pulumi, CDK — mais de nombreux systèmes plus anciens ont des années de configuration manuelle accumulée qu'il est impossible d'auditer ou de reproduire de manière fiable.
La dette de dépendances se distingue par son profil de risque externe. Un package que vous avez écrit ne peut pas soudainement développer une vulnérabilité d'exécution de code à distance. Un package écrit par un tiers le peut. Des dépendances obsolètes dans un logiciel activement maintenu sont une bombe à retardement.
Construire l'argumentaire métier pour rembourser la dette technique
C'est là que de nombreuses équipes d'ingénierie se retrouvent bloquées. L'argumentaire en faveur du traitement de la dette technique est évident pour les ingénieurs et opaque pour tout le monde. Voici comment le formuler.
Le cadrage par les paiements d'intérêts est le plus utile pour les parties prenantes non techniques. Chaque mois où vous portez une dette architecturale significative, vous dépensez un pourcentage de votre capacité d'ingénierie sur les frais généraux qu'elle crée — livraison de fonctionnalités plus lente, plus de bugs, cycles de débogage plus longs, déploiements plus prudents. Estimez le coût de ces frais généraux. Si votre équipe d'ingénierie coûte 50 000 € par mois et qu'une estimation raisonnable indique que les frictions liées à la dette consomment 30 % de leur capacité productive, vous payez 15 000 € par mois en intérêts. Ce cadrage fait de la réduction de la dette une conversation de retour sur investissement directe.
Le coût du statu quo est l'autre côté du bilan. La dette technique ne reste pas constante. Elle accumule des intérêts. La base de code gérable aujourd'hui sera plus difficile à travailler l'année prochaine et potentiellement ingérable l'année suivante. Le bon cadrage n'est pas « nous demandons trois mois pour nettoyer le code ». Le bon cadrage est « nous avons deux options : investir trois mois maintenant et récupérer notre pleine capacité de livraison, ou ne rien faire et regarder la capacité de livraison continuer à décliner, avec le travail de remédiation qui grossit et devient plus risqué à chaque trimestre de retard ».
Lorsque vous engagez des parties prenantes non techniques, quantifiez ce que vous pouvez et soyez honnête sur l'incertitude de ce que vous ne pouvez pas quantifier. Un graphique de la vélocité de livraison des fonctionnalités dans le temps, montrant une tendance à la baisse constante, est plus persuasif que tout argument technique.
Stratégies pour traiter la dette technique
Il n'existe pas d'approche unique pour rembourser la dette technique. La bonne stratégie dépend de la gravité de la dette, de la marge de manœuvre dont dispose l'entreprise et de la tolérance au risque de l'équipe.
La règle du boy-scout est l'approche la plus légère : laissez chaque morceau de code que vous touchez un peu meilleur que vous ne l'avez trouvé. Renommez une variable confuse. Extrayez un bloc répété dans une fonction partagée. Ajoutez un test pour la logique que vous avez modifiée. Cette approche nécessite de la discipline mais n'engendre aucun overhead supplémentaire — le travail se fait dans le flux normal du développement de fonctionnalités. Pour les équipes avec une dette modérée et une culture de la qualité, c'est souvent suffisant pour maintenir le cap et s'améliorer progressivement.
Les sprints de remaniement dédiés — allouer un pourcentage de chaque sprint, ou des sprints entiers périodiquement, à la réduction de la dette — sont appropriés lorsque la dette est suffisamment importante pour devoir être attaquée directement. Le pattern le plus courant est de réserver 20 % de la capacité de sprint aux améliorations techniques. Cela crée une cadence prévisible sans interrompre le développement de fonctionnalités, et cela force l'équipe à prioriser quelle dette traiter plutôt que d'essayer de tout corriger en même temps.
Le pattern de l'étrangleur (strangler fig pattern) est la bonne approche pour la dette architecturale qui ne peut pas être traitée de manière incrémentale. Nommé d'après le figuier étrangleur qui pousse autour d'un arbre existant et finit par le remplacer, le pattern consiste à construire un nouveau système bien structuré à côté du système legacy, en acheminant progressivement les fonctionnalités vers le nouveau système jusqu'à ce que l'ancien puisse être mis hors service. Il s'agit d'une alternative à plus faible risque à une réécriture big-bang car l'ancien système continue de fonctionner tout au long de la migration, et le nouveau système peut être validé de manière incrémentale.
La migration incrémentale versus la réécriture big-bang est le choix stratégique central lorsque la dette est grave. Dans presque tous les cas, la migration incrémentale est plus sûre. La réécriture big-bang part de l'hypothèse que vous pouvez geler l'ancien système, construire un remplacement complet et basculer à un moment défini. En pratique, les exigences changent pendant la réécriture, l'ancien système continue d'accumuler des modifications et le moment de la bascule n'arrive jamais proprement.
Quand réécrire plutôt que remanier
La réécriture complète n'est presque jamais la bonne réponse. Elle l'est cependant parfois. Les conditions qui justifient une réécriture complète sont spécifiques.
La base de code est dans un langage ou un framework qui n'a plus d'écosystème actif, ne peut pas être migré de manière incrémentale et ne peut pas supporter les exigences du produit même avec un remaniement significatif. Le système a été modifié tant de fois par tant de mains différentes qu'il n'a plus aucune cohérence interne, et le coût de sa compréhension est supérieur au coût de sa reconstruction. Les exigences métier ont changé si fondamentalement que le modèle de données et l'architecture centrale ne sont plus valides — pas seulement désordonnés, mais erronés.
Même lorsque toutes ces conditions sont réunies, la réécriture doit être limitée aussi étroitement que possible. Reconstruire un composant de zéro, avec des interfaces bien définies vers le reste du système, est catégoriquement plus sûr que tenter de reconstruire l'ensemble de l'application simultanément. « Faisons une réécriture complète » devrait être traité comme une proposition nécessitant un examen sérieux — car l'histoire des réécritures logicielles complètes n'est, franchement, pas encourageante.
Comment Cyberbeak aide ses clients à gérer leur dette technique
Nous travaillons régulièrement avec des entreprises dont les produits ont accumulé une dette technique significative — souvent sans que l'équipe actuelle comprenne pleinement l'étendue du problème.
Notre audit de base de code est un engagement structuré et délimité dans le temps, conçu pour donner à la fois à l'équipe technique et à la direction de l'entreprise une image claire de l'emplacement de la dette, de son coût et de ce qu'il faudrait pour y remédier. Nous examinons l'architecture et la structure du code, exécutons des outils d'analyse statique, auditons l'arbre de dépendances, évaluons la couverture de tests et interrogeons l'équipe d'ingénierie sur les parties du système qui créent le plus de friction dans le développement quotidien. Nous examinons le facteur bus, l'expérience d'intégration et les pratiques de déploiement et d'infrastructure.
Le livrable est un rapport écrit qui évite le jargon technique autant que possible, donne une vue priorisée de la dette par type et impact, et inclut une feuille de route de remédiation réaliste. Nous sommes explicites sur ce que nous recommandons et pourquoi, et nous sommes tout aussi explicites lorsque la bonne réponse est de vivre avec une certaine dette plutôt que de la rembourser — toute dette ne mérite pas d'être traitée immédiatement.
Lorsque les clients souhaitent procéder à la remédiation, nous délimitons soigneusement le travail, convenons de la bonne stratégie pour chaque catégorie de dette et travaillons aux côtés de l'équipe existante dans la mesure du possible. Nous croyons à laisser les équipes plus capables que nous ne les avons trouvées, ce qui signifie que l'objectif n'est pas seulement de corriger le code mais d'établir les pratiques qui empêchent la même dette de s'accumuler à nouveau.
Questions fréquentes (FAQ)
Toute dette technique est-elle mauvaise ?
Non. La dette contractée délibérément, suivie avec soin et remboursée lorsque les conditions le permettent est un outil d'ingénierie légitime. Le problème est la dette non gérée — une dette qui s'accumule sans conscience, qui n'est jamais suivie et qui n'est jamais traitée jusqu'à ce qu'elle devienne une crise. Le cadre des quatre quadrants est utile ici : une dette réfléchie et délibérée contractée avec l'intention de remanier une fois que l'on en a appris davantage est différente dans sa nature de la dette imprudente accumulée en ignorant les standards d'ingénierie sous la pression des délais.
Combien de temps faut-il pour corriger la dette technique ?
Cela dépend entièrement du type et du volume de la dette, de la taille de l'équipe et de l'approche adoptée. La dette au niveau du code et la dette de tests peuvent souvent être traitées progressivement sur des semaines et des mois sans interrompre la livraison de fonctionnalités. La dette architecturale — en particulier dans les grandes bases de code matures — peut prendre des mois, voire des années, à traiter, surtout si l'équipe le fait de manière incrémentale en parallèle du travail produit normal. Nous n'avons jamais vu de dette technique qui ne puisse pas être significativement réduite dans les six mois d'un effort concentré, mais nous avons aussi vu des dettes suffisamment graves pour qu'une résolution complète soit un programme pluriannuel.
Peut-on corriger la dette technique sans arrêter le développement de fonctionnalités ?
Dans la plupart des cas, oui. La règle du boy-scout et le modèle d'allocation de 20 % du sprint permettent tous deux à la réduction de la dette de progresser en parallèle du travail sur les fonctionnalités. L'exception est lorsque la dette est suffisamment grave pour bloquer activement le développement de fonctionnalités — dans ce cas, un sprint de remédiation concentré est souvent justifié, car continuer à ajouter des fonctionnalités sur une base peu fiable ajoute simplement plus de dette au niveau de la couche applicative par-dessus les problèmes structurels existants. L'argumentaire métier en faveur d'un bref gel des fonctionnalités est souvent plus simple que les équipes ne s'y attendent une fois que le cadrage par les paiements d'intérêts est appliqué.
Comment prévenir la dette technique dans un nouveau projet ?
Vous ne pouvez pas l'empêcher entièrement, mais vous pouvez l'empêcher de s'accumuler imprudemment. Les fondamentaux sont : imposer la revue de code comme une véritable conversation technique dès le premier jour ; définir une base de couverture de tests et la maintenir ; tenir les dépendances à jour selon une cadence régulière plutôt qu'en lots d'urgence ; rédiger des enregistrements de décisions architecturales (Architecture Decision Records) lorsque des décisions importantes sont prises ; traiter la base de code comme un actif partagé dont chaque membre de l'équipe est responsable de l'amélioration incrémentale. Construire avec une structure modulaire propre — même dans un monolithe — rend le travail de remaniement inévitable moins coûteux et plus sûr lorsqu'il arrive.
Si votre produit présente des signes d'accumulation de dette technique — livraison ralentie, développeurs appréhensifs, base de code qui a dépassé la compréhension totale de quiconque — nous serions heureux d'avoir une conversation directe sur ce à quoi nous avons réellement affaire et sur ce à quoi ressemble la voie réaliste à suivre. Nous avons fait ce travail de nombreuses fois. Nous vous dirons honnêtement ce que nous trouvons, et nous ne recommanderons pas plus de remédiation que ce que l'argumentaire métier justifie.
Parlez à notre équipe de votre projet
Nous travaillons avec des entreprises au Royaume-Uni, aux États-Unis, aux Émirats, en Arabie Saoudite, au Canada, en Australie et en Allemagne pour concevoir des logiciels sur mesure, des plateformes SaaS et des systèmes marketplace.