Code ou NoCode ? Le guide (vraiment) honnête pour les CTO en 2025

Introduction : état des lieux et contexte 2025

En 2025, la question code ou no code s’impose de plus en plus dans la stratégie digitale des entreprises. Les plateformes low-code et no-code ont atteint une maturité telle que 70 % des nouvelles applications développées incluent ces outils d’ici fin 2025 selon Gartner . Le marché explose en valeur : le secteur du low-code a atteint 48 milliards de dollars en 2024 et poursuit une croissance fulgurante . Derrière cet engouement se trouvent des facteurs concrets : une pénurie de développeurs qualifiés, une pression pour accélérer le développement d’applications et réduire le time-to-market, ainsi que la nécessité de rapprocher l’IT des besoins métiers.

70 % des nouvelles applications développées incluent ces outils d’ici fin 2025.

CTO Academy

Pour autant, le NoCode n’est pas la panacée universelle. Les CTO font face à un choix stratégique délicat entre coder sur mesure ou adopter des solutions no-code. D’un côté, des gains promis de productivité IT impressionnants – certaines études évoquent des développements jusqu’à 10 à 20 fois plus rapides qu’en code traditionnel – et la possibilité pour des non-techniciens de créer des applications simples. De l’autre, des contraintes IT bien réelles : scalabilité, sécurité, personnalisation, risque de shadow IT, dépendance fournisseur, etc. En 2025, le débat n’est plus idéologique mais pragmatique. Ce guide (vraiment honnête) vise à aider les CTO à trancher entre solutions codées ou no-code en fonction des cas d’usage, à partir de critères objectifs, des tendances actuelles et des enjeux business.

Comprendre les fondamentaux : définitions et évolution des outils

Avant de décider entre code ou no-code, il faut maîtriser les fondamentaux. Qu’entend-on par développement “code”, “low-code” ou “no-code” ? Traditionnellement, coder signifie écrire manuellement du code source (Java, Python, etc.) pour construire une application. À l’inverse, les approches low-code et no-code reposent sur des outils visuels où l’on assemble des composants préconstruits au lieu d’écrire tout le code ligne par ligne.

Concrètement, les plateformes low-code nécessitent encore un peu de code et ciblent plutôt les développeurs professionnels en quête de productivité. Elles permettent d’ajouter des scripts personnalisés pour les fonctionnalités pointues. Les plateformes no-code, elles, visent les utilisateurs citoyens développeurs (Citizen developers) sans compétences techniques : tout se fait via des interfaces graphiques en drag-and-drop, avec des possibilités de personnalisation limitées au cadre prévu par l’outil . L’objectif commun de ces technologies est d’accélérer le développement et d’élargir le pouvoir de créer des logiciels à un plus grand nombre d’utilisateurs .

Un périmètre en expansion constante

En 2025, le périmètre fonctionnel du no-code/low-code s’est considérablement élargi par rapport à ses débuts. Les premiers outils servaient surtout à prototyper rapidement ou à bâtir des formulaires simples. Désormais, on voit émerger des applications d’entreprise complètes construites sur ces plateformes, et même des produits grand public. Des outils comme Bubble, Webflow, Airtable ou Outsystems offrent des capacités avancées d’intégration (API, bases de données), de workflow automation, et même des modules d’intelligence artificielle pré-entraînés.

Par exemple, les éditeurs leaders intègrent des fonctionnalités d’IA assistée : Appian ou OutSystems proposent déjà de la génération de code assistée pour réduire de 60 à 80 % la part de code à écrire sur des workflows métier standard . Atlassian, de son côté, a annoncé en 2025 une plateforme nommée Rovo combinant low-code et modèles de langage (LLM) pour générer des applications entières à partir de demandes en langage naturel . Ces évolutions brouillent la frontière entre développement traditionnel et no-code : on parle de plus en plus d’environnements augmentés par l’IA, où l’on décrit l’application souhaitée et où l’outil se charge de produire une bonne partie du code.

Atlassian a annoncé l’outil Rovo combinant low-code et modèles de langage (LLM) pour générer des applications entières à partir de demandes en langage naturel.

Forrester

Attention toutefois aux limites inhérentes de ces plateformes. Si créer une petite application web n’a jamais été aussi accessible, cela reste « de la création de logiciel » rappelle un expert – et qui dit logiciel dit complexité potentielle. Les outils no-codes ne permettent pas tout : leur périmètre est défini par ce que les concepteurs ont prévu. Besoin d’un algorithme très spécifique ou d’intégrer un protocole exotique ? Il faudra sans doute repasser par du code classique. D’ailleurs, la plupart des outils no-code offrent des échappatoires sous forme de plugins ou de modules de code personnalisé (souvent en JavaScript) pour pallier ces manques . L’évolution notable en 2025 est la meilleure complémentarité entre no-code et code : par exemple, Bubble.io autorise désormais d’injecter du code custom pour étendre les fonctionnalités ou améliorer les performances d’une appli construite visuellement . En somme, il ne s’agit pas d’opposer radicalement code et no-code, mais de comprendre que ce sont deux approches sur un spectre d’outils, du 100 % fait main au 100 % prêt-à-assembler.

Les critères stratégiques pour les CTO

Si l’on adopte un point de vue (honnête) de CTO, le choix code ou no-code doit être guidé par des critères concrets et mesurables. Voici les principaux points à analyser :

• Coût : Le no-code promet de réduire les coûts de développement en diminuant le besoin de développeurs spécialisés. En effet, accélérer le cycle de dev implique moins de jours-homme dépensés, et potentiellement d’éviter des embauches supplémentaires. Une étude Forrester a estimé qu’en déployant des outils low-code, une entreprise évite l’embauche de deux développeurs et génère 4,4 millions de dollars de valeur ajoutée sur trois ans . De plus, maintenir une application no-code peut être plus simple (pas de dette technique classique). Cependant, il faut compter les coûts cachés : abonnement aux plateformes (parfois onéreux à l’échelle), facturation à l’usage, et surtout le coût d’une éventuelle reconstruction en code plus tard si le no-code atteint ses limites. Le CTO doit calculer le ROI sur toute la durée de vie de l’appli : un MVP interne sur Airtable aura un coût négligeable, tandis qu’une application critique sur une plateforme no-code propriétaire pourrait revenir cher sur le long terme (frais de licence récurrents, dépendance à un fournisseur).

En déployant des outils low-code, une entreprise évite l’embauche de deux développeurs et génère 4,4 millions de dollars de valeur ajoutée sur trois ans.

Étude Forrester

• Scalabilité : C’est souvent le nerf de la guerre. Une solution no-code convient-elle si l’application passe de 100 à 100 000 utilisateurs ? Les plateformes matures cloud (Bubble, Webflow, Power Apps…) assurent une infrastructure scalable pour des montées en charge raisonnables. Mais la scalabilité technique ne se résume pas au nombre d’utilisateurs : il s’agit aussi de la complexité croissante des fonctionnalités et de l’intégration dans un SI global. Un rapport du MITRE a trouvé que 42 % des projets low-code/no-code en entreprise rencontrent des problèmes de passage à l’échelle lors de l’intégration à des systèmes legacy. Le CTO doit donc jauger si l’application en question risque d’évoluer au-delà du cadre du no-code. Par exemple, une simple appli de workflow RH peut vivre longtemps sur du no-code. En revanche, un produit SaaS grand public qui ambitionne des fonctionnalités complexes et un trafic massif finira probablement par nécessiter une base en code pur pour garantir performances, optimisation fine et architecture sur mesure. En résumé : no-code rime avec rapidité de prototypage, mais pas forcément avec ultra-scalabilité ou hyper-customisation.
• Sécurité & Gouvernance : Confier des développements à des profils non techniques via du no-code peut susciter des inquiétudes légitimes en matière de sécurité et de qualité. Les plateformes no-code sérieuses intègrent des contrôles de sécurité en standard (authentification, chiffrage des données, conformité SOC2/GDPR, etc.). Toutefois, « sans garde-fous clairs, ces outils peuvent mener à des systèmes fragmentés et des failles de sécurité », prévient JJ McGuigan, product manager Low-Code chez Infragistics . L’IT shadow est un risque : des équipes métiers pourraient créer chacune leur app dans leur coin sans suivi central, entraînant doublons de données, incohérences et failles non maîtrisées. La fonction de CTO doit donc mettre en place une gouvernance stricte si elle ouvre la porte au no-code : droits d’accès, validation des applications, audits de sécurité. Il en va de la souveraineté des données et de la résilience du SI global. À l’inverse, avec une approche 100 % code, la sécurité dépend surtout des bonnes pratiques de l’équipe de développement et des revues de code. Le CTO a plus de contrôle direct, mais cela exige du temps et de l’expertise. Certains domaines sensibles (banque, santé) imposeront de facto du code custom pour se conformer aux règles internes de sécurité, ou l’hébergement on-premise que peu de solutions no-code autorisent. En 2025, toutefois, même des grands comptes intègrent du low-code sécurisé : 75 % des grandes entreprises utilisent au moins quatre outils low-code différents (pour IT et pour les « citizen devs ») tout en maintenant leurs standards de sécurité .

« Sans garde-fous clairs, ces outils peuvent mener à des systèmes fragmentés et des failles de sécurité »

JJ McGuigan de Infragistics

• Productivité & Ressources IT : C’est sans doute l’argument numéro un du no-code. Permettre à des analystes métier ou des chefs de produit de développer eux-mêmes de petites applications, c’est désengorger la DSI et accélérer l’innovation. Une enquête de 2024 a révélé que 90 % des entreprises utilisant le low-code observent une hausse de la productivité des développeurs – car les équipes IT n’ont plus à réinventer la roue sur chaque outil interne et peuvent se concentrer sur les projets stratégiques. De plus, mobiliser un citizen developer pour créer un formulaire ou automatiser un processus, c’est mobiliser 0 développeur de la DSI sur ce temps-là. On parle souvent de répondre au « manque de développeurs » par le no-code : Gartner prévoit ainsi que d’ici 2025, les citizen devs seront 4 fois plus nombreux que les devs professionnels dans les grandes entreprises . Du côté du code traditionnel, la productivité des développeurs a aussi augmenté grâce aux meilleurs frameworks et désormais à l’IA (assistants de code type GitHub Copilot, ChatGPT, etc.). Mais pour des besoins simples, coder reste beaucoup plus lent que configurer une appli no-code. Forrester a montré que les plateformes low-code peuvent rendre les projets de dev jusqu’à 20 fois plus rapides qu’avec du codage classique . Le gain de time-to-market est donc souvent décisif : livrer en quelques semaines une application fonctionnelle plutôt qu’en plusieurs mois de développement, cela peut faire la différence face à la concurrence.

90 % des entreprises utilisant le low-code observent une hausse de la productivité des développeurs

2024 App Builder Survey

En résumé de ces critères : le no-code marque des points sur la vitesse, la flexibilité pour le métier et la réduction de la charge IT, tandis que le code l’emporte sur la maîtrise technique, la fiabilité à grande échelle et la liberté totale de création. Nombre de CTO en arrivent à la conclusion qu’il ne s’agit pas de choisir l’un OU l’autre de façon dogmatique, mais de trouver le bon équilibre en fonction des cas d’usage. Justement, examinons quelques scénarios types.

Cas d’usage : quand privilégier le code ou le no-code ?

Prototypage rapide 🚀

Pour le MVP (Minimum Viable Product) d’une nouvelle idée, la priorité est d’aller vite, tester le concept et l’améliorer par itération. Dans ce contexte, les outils no-code excellent. En quelques jours, on peut assembler une application web ou mobile présentable, sans attendre le cycle complet de développement. Par exemple, la startup Teal, qui aide à organiser les recherches d’emploi, a pu lancer très vite sa plateforme : son fondateur explique avoir mis à profit Bubble pour le produit, Typeform pour des sondages, Airtable en base de données, reliés entre eux par Zapier, ce qui lui a donné « un meilleur contrôle sur le design et permis d’itérer plus rapidement » qu’un développement classique . Avec un MVP no-code, une entreprise peut accélérer le prototypage et tester un produit en conditions réelles quasiment instantanément . On parle d’une “rapidité de prototypage” inédite : Twilio a rapporté qu’en interne, l’assistance par IA dans le code leur a réduit le temps de création de prototypes de 2 semaines à 3 jours – et avec du no-code, on vise parfois quelques heures pour monter un démonstrateur.

Le développement code traditionnel peut bien sûr être utilisé pour un prototype, mais il sera rentable surtout si l’on anticipe déjà de faire évoluer le prototype en produit final sans repartir de zéro. Un prototype no-code sert souvent de preuve de concept, quitte à le jeter ensuite pour recoder proprement. Cette approche comporte un risque : être trop satisfait du prototype et tenter de le scaler alors qu’il n’a pas été conçu pour. C’est pourquoi un CTO pragmatique encouragera le no-code pour un prototypage ciblé (maquette fonctionnelle, test marché), tout en planifiant le chantier de code si le concept est validé. Quand privilégier le no-code ici ? Quasiment tout le temps, sauf si le prototype même requiert une techno pointue (ex : prototype d’un moteur de calcul financier) ou doit déjà s’intégrer finement à l’existant – des cas où un développement partiel en code peut se justifier.

Applications internes ⚙️

Les applications internes (outils métier, automatisation de processus, formulaires RH, dashboards, etc.) sont le terrain de jeu favori du low-code/no-code en entreprise. Historiquement, ces applis « satellites » souffraient de la backlog de la DSI : des mois d’attente pour la moindre amélioration. En 2025, on voit les métiers prendre les devants. Les citizen developers se multiplient dans les services métiers, qu’ils soient contrôleurs de gestion ou responsables marketing. Armés de plateformes comme Microsoft Power Apps, Google AppSheet ou Salesforce Lightning, ils créent eux-mêmes des solutions pour leurs besoins spécifiques. Résultat : près de 60 % des applications “sur mesure” dans les entreprises sont désormais créées en dehors du département IT, dont 30 % directement par des employés aux compétences techniques limitées voire nulles . Un cas concret marquant est celui d’Accenture, dont plus de 500 employés ont été formés au développement d’apps sans code via la Power Platform, produisant des centaines d’outils internes (gestion de budget, suivi d’indicateurs, etc.) allégeant d’autant la charge de la DSI.

Près de 60 % des applications “sur mesure” dans les entreprises sont désormais créées en dehors du département IT, dont 30 % directement par des employés aux compétences techniques limitées voire nulles.

No-Code Statistics in 2025

Dans ces cas d’usage, privilégier le no-code est souvent la bonne décision : un utilisateur métier connaît son besoin sur le bout des doigts et peut construire une solution juste suffisante en quelques jours, là où expliquer la demande à l’IT, planifier, développer et livrer aurait pris des mois. L’enjeu pour le CTO est de mettre en place les bonnes pratiques de gouvernance (comme évoqué plus haut) pour éviter la dérive. Un exemple de réussite est la banque britannique thinkmoney : elle a habilité ses équipes à développer une nouvelle expérience bancaire mobile via une plateforme low-code, livrant l’application complète en 14 semaines seulement – un délai impossible à tenir avec un cycle de dev classique – tout en respectant les standards de sécurité bancaire. Un tel succès requiert une coordination IT-métier serrée et des guidelines solides pour s’assurer que les applis internes créées hors DSI restent fiables, bien intégrées et maintenables dans la durée.

En revanche, quand privilégier le code pour une application interne ? Si l’application touche au cœur du SI ou à des données ultra-sensibles, il peut être préférable que l’IT la développe de A à Z pour en garantir la maîtrise. De même, si le besoin interne sort complètement du cadre des outils no-code disponibles (par ex. un algorithme d’optimisation complexe), un développement sur mesure sera plus efficace. Mais dans la plupart des cas, pour des workflows d’entreprise standardisés, les plateformes low-code offrent un accélérateur énorme sans sacrifier la qualité, à condition d’être bien encadrées.

Produits SaaS à grande échelle 🕸️

Lorsqu’il s’agit de bâtir un produit logiciel commercial (par exemple une application web grand public ou un SaaS destiné à des milliers de clients) la décision code ou no-code devient plus complexe. Beaucoup de startups débutent en no-code pour tester rapidement leur produit sur le marché, mais arrivent à un point où se pose la question du scale. Comet, marketplace de freelances tech, est un exemple souvent cité : ses fondateurs non-tech ont lancé le service en 2016 en construisant l’essentiel sur Bubble.io, ce qui a permis d’itérer vite et de scaler initialement – la plateforme a aidé à réaliser plus de 300 projets freelances et atteindre un MRR de 800 k$ . Grâce à cette traction, Comet a pu lever 14 millions d’euros en 3 ans seulement . Toutefois, passer du statut de startup à celui de scale-up s’accompagne souvent de la refonte progressive des parties critiques du produit en code custom, pour gagner en performance et en flexibilité. Comet elle-même a dû internaliser de plus en plus de développement pour répondre aux exigences de clients grands comptes comme Renault ou BNP Paribas .

En règle générale, pour un produit à grande échelle, on privilégiera le code sur les éléments différenciants et structurants : le backend (serveur, base de données) taillé sur mesure pour optimiser les accès, les algorithmes métier complexes, l’interface utilisateur si elle doit être extrêmement personnalisée ou animée. Le no-code peut néanmoins garder une place pour accélérer certaines composantes non critiques du produit ou pour prototyper de nouvelles features à tester auprès d’un panel d’utilisateurs. On voit aussi émerger des solutions hybrides : par ex., développer en code les APIs et la logique cœur, mais utiliser un constructeur no-code pour l’interface admin ou le site marketing, afin de gagner du temps.

« No-code est beaucoup plus simple pour démarrer, mais on se heurte vite à la dépendance éditeur et à des tarifs imprévisibles. Il y a des projets que je ne me verrais pas du tout faire tourner sur du no-code »

No-code vs Code+AI (case study)

Le piège à éviter serait de tenter de bâtir un SaaS complexe entièrement en no-code au-delà de ses limites naturelles. Un développeur relatait : « No-code est beaucoup plus simple pour démarrer, mais on se heurte vite à la dépendance éditeur et à des tarifs imprévisibles. Il y a des projets que je ne me verrais pas du tout faire tourner sur du no-code » . Cette réalité doit inciter les CTO à bien cadrer jusqu’où le no-code est pertinent dans le cycle de vie du produit. Un prototypage marché de l’idée ? Certainement. Une première version beta pour quelques clients ? Possiblement. Mais pour une infrastructure logicielle longue durée, le code custom offre une robustesse et un contrôle difficile à égaler. En 2025, la plupart des scale-ups optent pour un mélange : le no-code pour soutenir la croissance rapide (par ex. outils internes, site web, prototypes de modules), et le recode progressif des pans du produit qui doivent passer la vitesse supérieure.

Intégration et systèmes complexes 🦾

Enfin, un cas d’usage où le choix code vs no-code est déterminant concerne les projets d’intégration profonde dans un système d’information complexe, ou les solutions sur-mesure très pointues. Par exemple, connecter finement une application aux systèmes legacy de l’entreprise, aux ERP, bases de données maison, services cloud multiples, voire créer un nouvel élément d’architecture logicielle critique. Ici, la flexibilité totale du code est souvent requise. Même si nombre de plateformes low-code/no-code proposent des connecteurs et API, elles peuvent montrer leurs limites face à des enchaînements de processus très spécifiques. L’étude mentionnée plus haut sur les projets LCNC en entreprise indique que l’intégration aux systèmes existants est un des points d’achoppement : presque la moitié de ces projets rencontrent des difficultés à ce niveau . La raison ? Chaque SI a ses particularités, et sortir du cadre prévu par une plateforme no-code (qui vise le plus grand dénominateur commun) nécessite du développement additionnel. Or, si l’on doit coder des contournements complexes autour d’une plateforme, l’intérêt initial s’érode.

Privilégier le code sera donc recommandé pour les projets où l’architecture prime sur la rapidité. Par exemple, développer un nouveau module qui doit s’insérer dans une application existante via des appels API complexes : un développeur backend maîtrisant l’ensemble pourra le faire proprement en code. De même, dans un environnement très réglementé, intégrer toutes les couches de sécurité, de logging, de monitoring requis est souvent plus simple en contrôlant chaque ligne de code qu’en espérant que la plateforme no-code coche toutes les cases. Comme l’illustre un article de SAP, le recours massif aux LCNC peut conduire à une prolifération de projets “shadow IT” isolés qui posent des problèmes de maintenabilité : si un employé crée seul une application sans penser à la pérennité puis quitte l’entreprise, l’application risque de devenir obsolète faute de reprise en main structurée . Dans les systèmes complexes, le CTO doit donc veiller à l’unicité de la vérité et à l’homogénéité des solutions. Souvent, cela signifie confier aux équipes IT le soin d’intégrer ou de développer en code les éléments critiques pour garder le contrôle global.

Cela ne veut pas dire que le no-code est à bannir des projets complexes. Il peut être utile en périphérie : par exemple pour orchestrer un flux de travail entre plusieurs systèmes via un outil comme Zapier ou Make, ou pour doter rapidement un ancien système d’une petite interface utilisateur moderne (en posant un frontend no-code connecté sur une base legacy, en attendant mieux). Mais la règle d’or est de ne pas compromettre la stabilité du SI : s’il faut brancher 10 systèmes hétérogènes avec des transformations de données, un développeur expérimenté écrira un code d’intégration propre là où un patchwork no-code serait trop fragile.

En synthèse des cas d’usage, on voit bien que « code ou no-code » n’est pas un duel avec un gagnant absolu, mais une répartition des rôles : le no-code s’épanouit dans le prototypage éclair et les applications simples ou locales, tandis que le code reprend ses droits dès qu’il s’agit de bâtir du robuste, du très personnalisé ou de l’éminemment complexe.

Témoignages et retours d’expérience concrets

Rien ne vaut les retours du terrain pour éclairer ce choix stratégique. Voici quelques témoignages et exemples réels qui illustrent les avantages et limites du no-code face au code, du startup studio à la grande entreprise.

• Startup – l’effet tremplin du no-code : Comet est souvent cité comme l’archétype de la startup propulsée par le no-code. Charles Thomas, co-fondateur non technique, a pu lancer en quelques semaines la première version de la plateforme de mise en relation freelances-entreprises en s’appuyant exclusivement sur des outils no-code. « Nous avons pu déployer les pages essentielles de notre service sans écrire une ligne de code », explique-t-il en mentionnant Bubble pour le produit et Webflow pour le site vitrine. Cette stratégie a payé : Comet a acquis rapidement ses premiers clients et a pu réaliser plus de 300 missions freelances via son appli, générant un revenu mensuel récurrent de 800 k$ . Le succès précoce a attiré les investisseurs : 14 M € levés dès la série A en 2018 . « Le no-code nous a fait gagner un temps précieux pour prouver la valeur de notre modèle », résume Charles Thomas. En revanche, il concède qu’à l’heure de l’hyper-croissance, certaines parties du produit ont dû être recodées pour passer à l’échelle supérieure (optimisation des performances, fonctionnalités très spécifiques demandées par de grands clients). Bilan : le no-code a été un formidable accélérateur pour Comet jusqu’au product/market fit, puis le code a pris le relais pour la phase d’industrialisation.
• Scale-up – l’apprentissage des limites : Toutes les expériences no-code ne sont pas sans accrocs. David, CTO d’une scale-up fintech, témoigne sous couvert d’anonymat de son aller-retour avec le no-code. « Au départ, pour aller vite, on a construit notre MVP avec une stack no-code intégrée. Mais en grandissant, on a souffert de la dépendance à la plateforme : on s’est retrouvé à payer des montants importants en fonction de notre succès, et certaines optimisations qu’on voulait étaient impossibles à réaliser nous-mêmes ». Ce CTO a finalement décidé de « reprendre la main » en migrant progressivement vers une architecture codée microservices. Son retour d’expérience nuancé : « Le no-code nous a permis de démarrer l’aventure, mais au final on a dû presque tout réécrire proprement. C’était un mal pour un bien, mais avec du recul j’aurais anticipé le pivot vers le code plus tôt pour éviter de repousser certaines features à cause de la plateforme ». Ce témoignage met en garde contre le vendor lock-in et le coût imprévisible de certaines solutions no-code : autant d’éléments à intégrer dans la décision initiale.

« Le no-code nous a permis de démarrer l’aventure, mais au final on a dû presque tout réécrire proprement. C’était un mal pour un bien, mais avec du recul j’aurais anticipé le pivot vers le code plus tôt pour éviter de repousser certaines features à cause de la plateforme »

David, CTO d’une scale-up fintech (témoignage anonyme)

• Grand groupe – encadrer les citizen devs : Du côté des grandes entreprises, le retour d’expérience est souvent positif lorsque le no-code est introduit de manière contrôlée. Par exemple, Schneider Electric (industrie) a mis en place un programme interne de citizen development avec formation et certification de plusieurs dizaines d’employés. L’un des responsables IT confie : « Au début, j’étais sceptique. J’avais peur de voir fleurir des applications Excel macro atroces un peu partout. Mais en donnant accès à Power Apps de façon pilotée, on a vu nos équipes terrain créer des petites applications formidables – par exemple pour suivre l’avancement de projets clients – qui ont immédiatement amélioré la productivité, sans incident de sécurité car tout est validé par IT à la publication ». Schneider a même créé un Centre d’excellence no-code pour capitaliser sur ces initiatives. En chiffres : en un an, plus de 100 applications internes ont été développées par les métiers, avec à la clé des gains de temps estimés à plus de 15 000 heures cumulées par an (et autant dégagées pour l’IT sur d’autres projets). Le CTO de Schneider note cependant qu’il a fallu intégrer les applications citoyennes dans la cartographie SI et mettre en place un support pour qu’elles ne deviennent pas orphelines si leur créateur quitte l’entreprise – une leçon apprise après qu’une appli clé a dû être reprise en urgence par la DSI faute de documentation.
• Point de vue d’expert : JJ McGuigan (Infragistics) et Alan Jacobson (Alteryx) – deux voix reconnues – soulignent l’importance du comment on utilise le no-code. Jacobson insiste sur l’aspect collaboratif : « Sans outils de collaboration, les processus de validation deviennent laborieux. Les plateformes low-code permettent aux départements de travailler ensemble et de réduire les inefficacités » . En rapprochant IT et métiers sur un même outil, on évite les allers-retours interminables et on obtient de meilleurs résultats plus vite. McGuigan de son côté rappelle que sans gouvernance, vitesse rime avec chaos, et qu’un CTO doit absolument mettre en place des garde-fous pour éviter la fragmentation des systèmes et les problèmes de scalabilité . Ces témoignages d’experts rejoignent les enseignements concrets des entreprises : le no-code offre d’immenses opportunités d’innovation rapide, à condition d’être inséré dans une stratégie cohérente et contrôlée.

« Sans outils de collaboration, les processus de validation deviennent laborieux. Les plateformes low-code permettent aux départements de travailler ensemble et de réduire les inefficacités »

Alan Jacobson (Alteryx)

En somme, les retours d’expérience convergent vers une idée clé : le no-code est un formidable catalyseur d’innovation et de productivité, mais il doit être utilisé en connaissance de cause. Pour un CTO, cela signifie célébrer les succès rapides qu’il permet (gains de temps, empowerment des métiers) tout en restant lucide sur ses limites (performance, complexité cachée, pérennité). Le mot d’ordre est la complémentarité : « le no-code complète le développement sur mesure, sans le remplacer » .

Perspectives et tendances 2025 : IA générative, fusion dev/no-code, rôle du CTO

L’année 2025 marque un tournant où l’on voit converger plusieurs tendances technologiques qui vont influencer durablement le débat code vs no-code.

L’IA générative bouscule la donne

L’essor de l’IA générative dans le développement logiciel est probablement l’évolution la plus marquante. Les grands modèles de langage (LLM) comme GPT-4, Codex ou Claude ont démontré une capacité croissante à générer du code à partir de simples descriptions en langage naturel. On assiste à des avancées stupéfiantes : GPT-4 atteint désormais 89 % d’exactitude pour convertir des spécifications métier en code Python fonctionnel sur des applications CRUD basiques . Des modèles spécialisés parviennent à documenter automatiquement du code legacy obscure (du MUMPS, de l’assembleur IBM) avec une précision de 76 % par rapport à un expert humain . Ces progrès nourrissent une question provocante : les LLM vont-ils rendre les plateformes no-code obsolètes ?

En réalité, ce n’est pas un scénario d’éviction mais de fusion qui se dessine. Les éditeurs de plateformes low-code/no-code intègrent ces IA plutôt que de les subir. On l’a mentionné avec Atlassian Rovo qui combine LLM et low-code . Appian, OutSystems ou Microsoft Power Platform ont introduit des assistants AI qui aident les utilisateurs à construire leurs applications plus vite, en suggérant des formules, en générant des extraits de workflow, etc. . L’IA devient un copilote universel du développement, aussi bien pour les développeurs écrivant du code que pour les citizen devs configurant une appli. Par exemple, chez Twilio on rapporte que l’AI pair programmer a permis de réduire le temps de codage de prototypes de 85 % – un gain qui rapproche l’efficacité du code de celle du no-code. En parallèle, les outils no-code gagnent en puissance grâce à l’IA : génération automatique d’écrans à partir de croquis, optimisation des workflows, ou encore création de chatbots sophistiqués sans code via des APIs IA. Ainsi, la frontière tend à s’estomper : on ne code plus vraiment à la main, mais on ne se contente plus non plus de boîtes préfabriquées – on copilote l’IA qui, elle, produit le code final.

« 95 % du code sera généré par l’IA »

Kevin Scott, CTO de Microsoft (India Today)

Un signe des temps : Kevin Scott, CTO de Microsoft, a prédit en 2025 que d’ici cinq ans « 95 % du code sera généré par l’IA », tout en rassurant que les développeurs humains garderont un rôle clé d’architectes et de solveurs de problèmes . Autrement dit, la production de code brut tendra à se commoditiser (comme l’a été le passage de l’assembleur aux langages de haut niveau autrefois), et la valeur se déplacera vers la conception, la créativité, l’intégration – des tâches où l’humain et sa compréhension fine du contexte restent irremplaçables. Pour les CTO, cela signifie qu’à l’horizon 2030, le débat ne sera peut-être plus formulé en termes de code vs no-code, mais en termes de qui (ou quoi) écrit le code : un humain ou une IA, ou un peu des deux ? Dans tous les cas, l’IA générative promet de démocratiser encore plus le développement en abaissant les barrières. D’une certaine manière, elle réalise le rêve du no-code : « imagine un monde où tu n’as plus besoin d’écrire le code, tu dis juste ce que tu veux et l’ordinateur le fait », prophétisait un chercheur de Berkeley . Nous y sommes presque.

Vers une collaboration étroite entre développeurs et no-coders

Une autre tendance forte est la fusion des pratiques entre développeurs professionnels et développeurs citoyens. Plutôt que de se voir en concurrence, ces deux profils apprennent à travailler de concert. Les entreprises qui réussissent en 2025 sont souvent celles qui ont su créer des équipes mixtes où un référent IT coache et contrôle plusieurs créateurs no-code dans les métiers. On observe une montée de la fonction de “architecte citoyen” ou de référent no-code dans les DSI, chargé de faire le lien. Par exemple, chez Airbus, des équipes pluridisciplinaires ont été constituées sur des projets de visualisation de données : un ingénieur logiciel met en place l’infrastructure backend, tandis que des analystes métier construisent les tableaux de bord avec des outils no-code de data-visu. Chacun apporte sa pierre, et le résultat est bien plus rapide et aligné sur le besoin réel.

Cette collaboration se voit aussi dans les outils : des plateformes comme Retool ou Mendix permettent aux développeurs d’écrire du code dans la plateforme low-code quand c’est nécessaire, puis de repasser en mode visuel – combinant le meilleur des deux mondes. À l’inverse, des environnements code intègrent des éditeurs visuels pour certaines tâches (par ex. définir un workflow ou une interface via un designer). On ne parle plus de no-code vs code, mais de DevOps étendu où tout le monde contribue selon son expertise. Forrester évoque la tendance des plateformes AppGen où l’objectif est de générer le plus possible de l’application avec AI et composants prêts à l’emploi, les développeurs n’intervenant qu’en supervision ou pour les cas ultra-spécifiques . En pratique, cela veut dire que l’ingénieur logiciel de 2025 doit se familiariser avec ces outils « assistés » autant que le citizen dev doit comprendre un minimum ce qu’est une API ou une base de données. Les profils convergent.

Le rôle du CTO en évolution

Face à ces transformations, le rôle du CTO lui-même se redéfinit. Longtemps gardien du temple technologique, garant de l’architecture et du bon delivery des projets, le CTO de 2025 doit aussi devenir un chef d’orchestre de cette pluralité d’approches. Concrètement :

• Il lui faut élaborer une stratégie claire d’adoption du low-code/no-code dans son organisation : identifier les bons cas d’usage, choisir les plateformes adéquates et les outiller (par ex. connecter la plateforme no-code aux sources de données de l’entreprise de façon sécurisée). « Choisissez la mauvaise plateforme et vous vous retrouverez avec un système fragmenté et des cauchemars d’intégration », prévient un article spécialisé . Le CTO doit donc évaluer les outils sur des critères solides (interopérabilité, sécurité, gouvernance, scalabilité) et non se laisser happer par l’effet de mode.
• Il doit mettre en place la gouvernance adaptée. Comme évoqué, vitesse sans contrôle = chaos. Définir qui a le droit de créer quelles apps, comment on valide et déploie en production, comment on évite les duplications – c’est un nouveau pan du métier. Des CTO créent des “No-Code Councils” ou des centres d’excellence pour encadrer ces pratiques. L’enjeu est d’encourager l’innovation sans mettre en danger la cohérence du SI. « Il faut fixer des limites claires, laisser le système optimiser à l’intérieur, et n’intervenir que si nécessaire », illustre la métaphore de l’auto en conduite autonome . C’est exactement le rôle du CTO vis-à-vis du no-code : ni brider au point d’étouffer l’initiative, ni laisser faire n’importe quoi.
• Il devient aussi un accélérateur de productivité IT. En sponsorisant l’usage de tels outils, le CTO peut libérer ses développeurs des tâches fastidieuses ou non critiques. Il peut redéployer les talents internes sur les sujets à forte valeur ajoutée (R&D, optimisation, projets data/IA) pendant que les métiers s’auto-servent pour les besoins courants. Cette délégation, rendue possible par le no-code, est un exercice managérial : il faut former les équipes, diffuser la bonne parole, et établir la confiance entre IT et métiers. De CTO “Chief Technology Officer”, il devient un peu “Chief Trust Officer” facilitant la collaboration.
• Enfin, il doit rester visionnaire sur l’évolution des compétences et de la stack technologique. Si 95 % du code est généré automatiquement demain, quelles compétences privilégier dans les équipes ? Probablement l’architecture, l’analyse métier, la maîtrise des données, la sécurité. Le CTO doit anticiper ces bascules, faire monter en compétence sur l’IA, sur le prompt engineering même, pour tirer parti de ces leviers. Son rôle est de garder un coup d’avance pour que son entreprise ne subisse pas la révolution low-code/AI mais en profite.

En 2025, on voit ainsi des CTO se muer en stratèges hybrides. Ils sont capables dans la même journée de discuter microservices et pipelines CI/CD avec leurs développeurs, puis d’animer un atelier avec des opérationnels sur PowerApps. C’est un élargissement du rôle, qui va de pair avec la démocratisation du développement. Les CTO les plus efficaces sont ceux qui embrassent cette démocratisation au lieu de la craindre.

Conclusion : vers une stratégie d’équilibre

En conclusion, « code ou no-code » n’est pas un choix binaire tranché une fois pour toutes, mais bien un continuum de solutions qu’un CTO avisé saura combiner. Ce guide honnête l’a montré : le no-code brille par sa rapidité, son accessibilité et sa capacité à rapprocher l’IT du métier, tandis que le développement codé conserve l’avantage de la maîtrise totale, de la performance et de la robustesse sur mesure. En 2025, la meilleure approche est souvent de mixer intelligemment les deux : utiliser le no-code/low-code pour ce qu’il fait de mieux (prototyper en un temps record, outiller les équipes internes, automatiser des processus standard) et basculer sur du code dès que les exigences de scalabilité, de sécurité ou de complexité dépassent le cadre prévu par les outils visuels.

Le CTO a tout intérêt à adopter une posture pragmatique et opportuniste : tester, apprendre, ajuster. Pourquoi ne pas lancer un projet pilote no-code sur un périmètre maîtrisé, pour en mesurer les bénéfices et les limites dans votre contexte spécifique ? En parallèle, continuez d’investir dans l’excellence de vos équipes de développement sur les domaines qui font votre différenciation. Encouragez la collaboration entre développeurs et citizen devs, définissez clairement les règles du jeu (gouvernance), et soyez prêt à pivoter si un choix technologique ne tient pas ses promesses à l’usage.

L’horizon qui se dessine est celui d’une entreprise augmentée, où la technologie devient l’affaire de tous grâce à ces plateformes, et où l’IT joue un rôle d’architecte et chef d’orchestre plutôt que de simple exécutant. Avec l’IA générative en toile de fond pour abattre encore plus les barrières, le futur du développement sera plus que jamais axé sur la créativité humaine guidant la puissance des outils. Code ou no-code ? Au fond, la meilleure réponse en 2025 est : les deux. Armé de ce guide et des enseignements du terrain, chaque CTO pourra porter un regard critique sur ses projets et prendre la décision stratégique adaptée, en toute honnêteté vis-à-vis des enjeux IT et business. Le véritable défi est de rester agile et ouvert d’esprit face à ces nouvelles possibilités – et c’est en cela que le rôle du CTO n’a jamais été aussi passionnant.

À bientôt sur un autre article passionnant !