En tant que CTO chez Jimdo, j'ai souvent observé que l'innovation en matière d'applications était souvent décrite comme un événement monolithique : un processus de transformation numérique ou de migration cloud considéré comme une initiative ponctuelle qui, une fois achevée, permet à l'entreprise de se concentrer sur d'autres priorités. Or, ce processus n'est pas un projet assorti d'une date de début et d'une date de fin. Il s'agit d'un principe opérationnel qui doit être intégré au sein de votre culture technique.
La véritable problématique auxquels les dirigeants techniques doivent faire face n'est pas le choix entre fonctionnalités novatrices et impératifs de maintenance. Elle réside dans la gestion continue de votre dynamique en matière d'ingénierie. Lors d'un récent entretien avec Trey Guinn, Field CTO de Cloudflare, dans le cadre de l'émission Beyond the App Stack (Au-delà de la pile applicative), nous avons discuté de cette même tension : comment s'assurer que l'agilité ne se fasse pas au détriment de la stabilité.
Pour moi, la réponse commence par l'alignement. Je ne crois pas au consensus, car il est très difficile à obtenir au sein d'une entreprise en pleine croissance. Je crois plutôt en l'association d'une stratégie descendante et d'une exécution ascendante. L'équipe de direction définit les « quoi » et les « où », mais ce sont les ingénieurs et les vice-présidents qui déterminent les « comment ». Cette transparence constitue le seul moyen de nous assurer que lorsque nous parlons d'innovation des applications, nous parlons en réalité de croissance de l'activité.
Pour mettre en pratique notre plan de reprise, nous avons adopté ce que nous avons appelé une « taxe de stabilité » : 60 % des efforts allaient à la résolution de la dette technique principale, tandis que les 40 % restants étaient consacrés à l'innovation. Il ne s'agissait pas là d'un nombre magique, mais d'un socle tactique sur lequel nous fonder pour empêcher nos équipes de trébucher sur les débris de notre base de code.
Le secret de la cohérence ne réside pas dans le fait de s'en tenir éternellement à un ratio fixe, mais dans la nécessité d'évaluer le niveau de friction au sein de votre équipe. Si les déploiements se révèlent lents et la complexité élevée, les efforts alloués à votre dette technique (la « taxe ») doivent augmenter. Après avoir fait preuve de rigueur pendant trois ans, nous avons mérité le droit d'inverser la tendance. Nous investissons aujourd'hui davantage dans l'innovation, mais ne cessons jamais de travailler à la réduction de notre dette technique. Que vous soyez à 60/40 ou à 20/80, la règle est la même : vous devez régler les dettes de votre passé pour protéger votre avenir.
L'une des décisions les plus difficiles qu'un CTO doit prendre consiste à déterminer à quel moment un système est irrécupérable. La tentation de «mettre le feu à l'ensemble du bâtiment » et de repartir de zéro est constante, mais selon mon expérience, cette décision doit être dictée par la stratégie opérationnelle et non par la frustration technique.
À un moment de son histoire, Jimdo a dû faire face à un tournant stratégique. Nous venions de quitter une solution de développement web « maison » au sein de laquelle les utilisateurs avaient besoin de connaissances en HTML et en CSS pour passer à l'ère du web 2.0 où nous étions proposions directement le site web aux utilisateurs. Comme le modèle économique avait changé à un échelon fondamental, notre solution existante devenait davantage un obstacle qu'un catalyseur. Nous avons dès lors isolé une équipe chargée de la responsabilité principale de rebâtir Jimdo 2.0.
Cette expérience a codifié la manière dont j'évalue chaque évolution technique majeure aujourd'hui. Elle m'a appris qu'un processus de modernisation ne doit pas porter uniquement sur la question de la résolution de la dette technique, mais également répondre à un problème opérationnel. Désormais, lorsqu'un responsable technique vient me voir pour me demander d'investir massivement dans l'innovation en matière d'applications, je lui pose toujours trois questions simples :
En quoi cette fonctionnalité nous permet-elle d'être plus rapides ?
En quoi nous permet-elle de simplifier notre fonctionnement ?
En quoi améliore-t-elle notre taux de conversion des produits ?
Si la proposition s'aligne étroitement sur la stratégie de l'entreprise et répond à ces trois questions, nous la validons et la mettons en œuvre pour le trimestre. La responsabilité est essentielle. L'idée ne consiste pas uniquement à demander un budget, mais également de présenter un argumentaire capable de justifier cet investissement.
L'innovation nécessite des systèmes permettant l'expérimentation, sans entraves. Jimdo protège l'idée d'une journée dédiée chaque semaine, c'est-à-dire au moins une journée pendant laquelle nos techniciens peuvent explorer des outils, tester des améliorations de notre base de code existante et s'informer sur les évolutions de l'univers de la technologie.
En tant qu'ingénieur dans l'âme, je pense qu'un technicien qui n'effectue pas de recherches et n'apprend rien ne peut pas conserver sa pertinence. À l'ère de l'IA, cette problématique se révèle plus vraie que jamais. En permettant aux entreprises de coder considérablement plus vite, l'IA change la donne. Il n'est toutefois possible d'assurer sa réussite avec l'IA qu'après avoir mis en place les garde-fous appropriés. J'encourage nos collaborateurs à étudier ces outils et à trouver des moyens d'accélérer leurs tâches. Cet investissement dans la curiosité commence d'ailleurs déjà à porter ses fruits.
Nous utilisons des canaux de communication internes pour diffuser ces découvertes. Le fait que chacun travaille vers le même objectif et voie clairement ce que leurs pairs développent entraîne une pression saine visant à rester aligné.
Tous les efforts d'innovation en matière d'applications ne sont pas couronnés de succès. J'ai connu mon lot d'échecs, notamment un projet d'investissement particulièrement difficile qui est resté opérationnel pendant plus de deux ans.
Le problème résidait dans le fait que le marché était passé à autre chose, que notre stratégie d'entreprise avait changé et que nous nous retrouvions avec un projet à moitié terminé qui ne correspondait plus aux besoins de notre activité. Ce projet s'est révélé extrêmement douloureux à maintenir. J'ai toutefois tiré une leçon vitale de cet échec : toujours diviser le travail en différentes étapes afin de s'assurer que la voie empruntée est la bonne.
Pensez-y comme au processus de construction d'une voiture. On ne construit pas quatre roues, puis un essieu. On commence par construire un skateboard, puis un vélo, puis une voiture. En effectuant vos « livraisons » sous la forme de petites étapes successives, vous vous protégez. De même, vous pouvez mettre un terme au projet sans perdre deux années de travail si votre stratégie change ou si le marché évolue. L'agilité ne se mesure pas uniquement à la rapidité. Elle inclut également la capacité à s'arrêter lorsque le chemin emprunté n'est plus le bon.
Il n'existe pas de recette simple à suivre pour bien faire les choses. Un leadership fort est une condition sine qua non pour protéger la capacité technique nécessaire au remboursement de la dette technique, surtout face à la pression constante en vue du lancement de nouvelles fonctionnalités.
Comme le révèle le rapport Cloudflare 2026 consacré à l'innovation en matière d'applications, les entreprises les plus performantes sont celles qui prédisent et planifient cette innovation à grande échelle et au fil du temps. Elles considèrent ainsi la technologie non pas comme une ressource statique, mais comme un système vivant qui nécessite des soins constants.
L'innovation en matière d'applications consiste à s'assurer que le temps consacré à l'amélioration de ces dernières soit fructueux. En donnant à vos équipes la latitude indispensable pour se tenir informées, la clarté nécessaire pour s'aligner sur les objectifs de l'entreprise, ainsi que la discipline suffisante pour leur permettre de réduire la dette, vous n'assurez pas uniquement la maintenance d'un produit, vous bâtissez un moteur concurrentiel.
La véritable innovation en matière d'applications concerne moins le fait d'atteindre un objectif que de faire évoluer la manière dont votre entreprise conçoit, protège et déploie des ressources numériques. Afin de transformer l'agilité technique en un avantage commercial permanent, vous avez besoin d'une infrastructure capable d'éliminer les frictions, tout en maintenant des normes de sécurité rigoureuses.
La plateforme unifiée d'amélioration de la sécurité et des performances des applications proposée par Cloudflare a été conçue spécifiquement pour soutenir cette évolution. À l'heure où les entreprises modernisent leurs systèmes existants, optimisent leurs architectures distribuées et investissent dans les capacités pilotées par IA, Cloudflare leur propose un socle capable d'équilibrer l'innovation et la résilience. En intégrant des performances de renommée mondiale, une observabilité approfondie et des outils orientés développeurs à une couche programmable unique, Cloudflare vous aide à optimiser le temps consacré à l'ingénierie et à stimuler l'innovation, sans les frais généraux imposés par l'utilisation d'outils disparates ni hausse incontrôlable des coûts.
Cet article fait partie de notre série consacrée aux nouvelles tendances et évolutions susceptibles d'affecter les décideurs en matière de technologies d'aujourd'hui.
Vous trouverez davantage d'informations sur la manière dont les entreprises modernisent leur pile applicative et leurs processus dans notre rapport Cloudflare 2026 sur l'innovation en matière d'applications.
Felipe Furlan — @ffurlansilva
CTO, Jimdo
Cet article vous permettra de mieux comprendre les aspects suivants :
Les moyens qui vous permettront d'équilibrer l'innovation avec les tâches de maintenance routinières
Le moment où procéder à une reconstruction, à un remaniement ou à un investissement pour réduire votre dette technique
Les critères d'évaluation des propositions de modernisation