Duck conf 2025 : Modern Software Engineering & Architecture - Les Tech Trends 2025
La Duck Conf est la conférence de l’architecture de SI by OCTO Technology. L’édition 2025 s'est tenue le 19 mars.
Le talk : « Modern Software Engineering & Architecture - Les Tech Trends 2025 » est assuré par Antoine CHANTALOU leader de la practice Software Engineering chez OCTO Technology.
Pour cette conférence, Antoine se restreint à une sélection des Tech Trends que l’on croisera cette année.
2025 reste une année complexe avec la démocratisation de la GenAI, les enjeux du sustainable et la régulation IT, la résurgence des enjeux de souveraineté, l’archipélisation des lieux de travail post-COVID : le travail en hybride ou en remote complexifie la façon de produire du logiciel.
Enfin, il faut ajouter le contexte socio-économique qui est sous tensions.
Cette complexité ne doit pourtant pas engendrer de fébrilité, en effet il faut se souvenir de cette citation de Le Corbusier :
« L’architecture est le point de départ lorsqu’on veut conduire l’humanité vers un avenir meilleur. »
Rappels chronologiques de l’architecture et des changements de paradigmes.
Globalement on distingue 2 grandes vagues : La première vague qui démarre dans les années 80 avec le Mainframe, la seconde qui prend son essor avec l’arrivée des smartphones.
On constate une décentralisation dans les paradigmes d’architecture.
Antoine définit cette problématique centrale : « Quelle architecture pour apprivoiser 4 Tech Trends phares de 2025 ? »
L'IA générative réalise un véritable hold-up !
Antoine balaye le sujet et invite à venir se délecter du talk de Nicolas LAURENT : « Coder une application inconnue en 30 min grâce à l’IA : buzz ou révolution ? »
Le Développement augmenté par l’IA
Il ressort actuellement que la GenAI donne de bons résultats pour générer des « blocs de code », des PoC, de la documentation.
La course aux chiffres des gains de productivité, laisse émerger quelques mythes… Une prise de recul est nécessaire !
OCTO Technology s’est lancé dans une analyse comparative de données issues de Microsoft versus des données expérimentales internes à OCTO.
D’après l'étude « Today was a Good Day : The Daily Life of Software Developers », la part pour produire et modifier du code représente 40% d’une journée type d’un développeur. Les gains s’appliquent donc à cette part. Il ressort de l’estimation terrain que le gain d’optimisation globale se situe entre 10% et 15% (résultats à prendre avec des précautions).
Cependant les gains de productivité ne sont pas équi-répartis et se différencient selon la maturité des développeurs : Un développeur expert tirera peu de bénéfices de l’IA, les développeurs de niveau intermédiaire à avancé en bénéficieront le plus, a contrario un développeur débutant pourrait être victime des hallucinations générées et par conséquent faire baisser la qualité du code en introduisant des régressions, des bugs et in fine faire baisser de productivité.
Pour se prémunir des effets négatifs qui pourraient advenir, il faut prévoir de backer et accompagner les développeurs les plus juniors par des pratiques de software craftsmanship. Ainsi, dans la constitution des équipes, il faut inclure des développeurs séniors pour conserver les pratiques de TDD, Pair Programming, Pair Review.
A ces conditions les gains peuvent devenir réels.
Quid du retrofit de la GenAI dans les apps ?
Comment appeler concrètement la GenAI ou comment fait-on du retrofit de la GenAI dans nos applications (site Web, App mobiles, etc.) ?
Prenons de la hauteur, il existe aujourd'hui 4 méthodes d’adaptation des LLM :
PE (Prompt engineering) : Des appels d’API pour générer du texte, des images, de la voix, etc.
RAG (Retrieval Augmented Generation) : plus compliqué à mettre en œuvre. Il s’agit de prendre une base documentaire pour ingestion dans une base vectorielle, afin de donner du contexte au moteur et obtenir des réponses beaucoup plus pertinentes.
Les 2 méthodes PE et RAG sont à privilégier car la complexité et les coûts sont maîtrisables, et par ailleurs l’impact environnemental est moindre comparativement au Fine Tune (FT) et Build Your Own (BYO).
Mais alors comment faire du retrofit de la GenAI dans les apps ?
Prenons l’exemple d’une Web App de e-commerce qui dispose d’un Backend For Front (BFF) appelant une API de paiement : de façon analogue, une façade GenAI appellera un ou plusieurs GenAI providers.
Il s’agit donc essentiellement d’un chantier d’intégration.
Pas de révolution d’architecture si on a déjà lancé l’« API-sation » du SI et à condition de répondre aux problématiques sécuritaires inhérentes.
Points de vigilances de la GenAI :
- Les tests sont non déterministes et laissent apparaître de nouvelles problématiques
- Souveraineté et propriété intellectuelle de ce qui est généré (mais l’habitude a déjà été prise lors du « Move to Cloud »)
- Complexité en cas d’utilisation des méthodes d’intégration FT, BYO des LLM.
Architectures composables
Ou comment bâtir des systèmes flexibles et adaptatifs par assemblage à la manière de LEGO®.
Est-ce que l'architecture M.A.C.H. serait celle du « One architecture to rule them all » ?
En effet, on observe une stabilisation des technologies et des écosystèmes sur ces 4 types d’architectures :
Microservices : ensemble de composants indépendants (build & run), autonomes sur leurs silos verticaux. Cette tendance accentue le phénomène de décentralisation. Ce découpage a repoussé la complexité vers la gestion inter-services, mais également sur l’organisation : agilité, scrum de scrum, le déploiement et sans oublier le troubleshooting. Cette stratégie devient intéressante à partir d’une certaine complexité. L’attention doit être portée sur la granularité.
API-first, partager les données et ré-utiliser les services (ATAWAD, Drink You Own Champagne, 100% d’API coverage). Pour industrialiser la consommation et monétiser de nouveaux modèles d’affaires. Le piège reste de mettre en œuvre des solutions d’API Management sans considérer les enjeux d’organisation et le cycle de vie des API.
Cloud-native ou applications qui respectent les twelve-factor. Indispensable. En phase d’innovation et de croissance, le Cloud public sera une cible de choix. En effet, tenter de rattraper les services managés des Cloud Providers, qui ont 15 ans d’avance, est illusoire. Autour des enjeux de souveraineté, on ressent aujourd’hui un revirement pour faire davantage de Cloud privé avec des partenaires de confiance ou encore du on premise. Tant que l’on respecte les twelve-factor il est facile de déplacer ses App en raison, notamment, de l’explosion de la facture Cloud. Les systèmes legacy peuvent-être déployés sur des Cloud moins performants. A contrario, l'enjeu pourrait être le rapatriement des données sensibles. Ces données forgent la conviction que le Cloud hybride est la voie à suivre.
Headless : consiste à séparer le front du back d’un monolithe (ou lui couper la tête). Ce pattern vise à gagner en TTM. En prenant l’exemple d’une solution vendor monolithique intégrée, au bout d’un certain nombre d’années, les douleurs surgissent lorsque l’on veut livrer rapidement. C’est le moment de découper le monolithe en développant un front custom (REACT, Angular, etc.) tout en conservant la solution vendor qui fait très bien le métier que l’on « API-ifie » (API sur étagère, ou la « façader »).
En conclusion
Il faut se lancer dans la mise en œuvre de l’architecture MACH à condition de rester pragmatique. Chercher l’inspiration auprès de Zendaya : « I love simplicity ».
Trois principes :
- Partir d’abord sur un Majectic-monolith pour un découpage ultérieur (recommandation de Martin FOWLER)
- Granularité au niveau DDD : pas de micro découpage, la « bonne » étant celle du domaine métier
- Event Driven Architecture (EDA) : pour sortir d’une position dogmatique, les événements permettant de répondre à de nombreux cas d’usages (broadcast d’events, réplication de backend ne tenant pas la charge, synchronisation de données, etc.).
Ainsi, 2025 sera l’année où le monolithe fera son come-back sous une forme « majestueuse » en réaction à la complexité tirée par les architectures microservices des dernières années.
Antoine invite à poursuivre le sujet avec le talk : « L’architecture continue par la pratique » de Pierrette BERTRAND et Pierre-Jean DOUSSET.
Efficience opérationnelle, sustainable avec EROOM, brownfield
Rappel de la loi de Moore : « le matériel double de puissance tous les 2 ans ».
On assiste, cependant, à un tassement depuis 2015 concernant les CPU.
Avec la raréfaction des ressources matérielles, Tristan NITOT nous invite au changement de paradigme grâce à une nouvelle loi : erooM (Effort Radicalement Organisé d’Optimisation en Masse). Loi qui nous enjoint à :
« optimiser nos applications et systèmes d’un facteur 2 tous les 2 ans ».
Bien que le Greenfield reste tentant, 2025 sera l’année du Brownfield, pour la reprise de contrôle du legacy et des assets existants. Finalement, le brownfield sera vraisemblablement plus vert que le Greenfield ! Pour plusieurs raisons :
- Moins risqué car cette approche permet de délivrer de la valeur rapidement (pas besoin d’attendre la refonte, le système étant en place)
- Le succès d’une refonte n’est pas garanti !
- Capitaliser sur l’architecture, les technologies et l’infrastructure en place.
Antoine propose cette caricature : le brownfield serait le « vinted » de l’architecture face à la fast fashion que représenterait le greenfield où l’on recrée des systèmes tous les 2 ans.
Comment faire du Brownfield ?
Une démarche scientifique : diagnostic et traitement.
- Une équipe collecte les symptômes et les douleurs pour dresser un diagnostic technique et humain (comme la perte de maîtrise fonctionnelle et/ou technique de l’application)
- Le traitement est souvent le même : changer le geste en réintroduisant du software craftsmanship pour reprendre le contrôle. Les frameworks, les technos, ne constituent pas le plus important. Les patterns et les algorithmes sont toujours présents. Antoine propose de rendre « sexy » les systèmes existants. Cela ne sera pas simple, la séniorité sera là encore à appeler à la rescousse. Pour contrôler l’état de santé du patient et s’assurer d’une non dégradation, il faudra mettre en place des métriques : les DORA metrics sont souvent les plus pertinents dans ce contexte.
Les étapes :
- Une approche itérative où plusieurs passes amèneront à une reprise de contrôle, et un état d’optimisation suffisant
- Revenir sur le pattern headless, façader le système existant et capitaliser sur la partie backend pour gagner 4-5 années
- Enfin, si les limites du backend sont atteintes, on partira sur un découpage avec refonte par domaines avec de nouvelles technologies et des API.
Sécurité : Zero Trust Architecture (ZTA)
Le modèle traditionnel de sécurité périmétrique est challengé, notamment par l’approche cloud-native mais aussi par l’archipélisation des lieux de travail post COVID.
Il devient difficile de voir le SI comme un château fort (avec des VPN, des firewall).
Le challenge est d’autant plus important lorsque l’on veut mettre en place une architecture continue et composable.
La ZTA repose sur 4 piliers :
- Vérifications systématiques et strictes (authentification et autorisation, MFA)
- Principe du moindre privilège
- Prévention des mouvements latéraux
- Vérifications contextualisée (identité, localisation, analyse comportementale, horaires d’accès)
En 2025, et si l’on sécurisait (vraiment) nos APIs ?
Concrètement la ZTA conduit à :
- Ne plus exposer d’API « en interne »,
- Pour les partenaires en sécurité périmétrique : ne plus faire appel aux : VPN, filtrage IP, certificats TLS, etc.
- Ne plus sécuriser par « compte de service », API-Key, etc.
Pour sécuriser en profondeur, il faut mettre en place les protocoles sécuritaires, bien connus, du web : OAUTH 2, OpenID Connect (OIDC) sur tous les Majestics-monoliths et sur tous les composants MACH.
Cette approche permettra de respecter ce que nous dit Ian ROBINSON : « Be of the web, not behind the web ».
Réponses en terme d’architecture :
La ZTA consiste, le plus souvent, à déployer une API Gateway couplée à une solution d'Identity Access Management (IAM) pour sécuriser l’accès à nos monolithes et microservices.
Qu’ils soient déployés sur un cloud privé, publique ou on premise : on systématise les
contrôles Authentification et Autorisation en ajoutant du contexte et le principe du moindre privilège.
Pour aller plus loin :
Livre blanc des Tech Trends 2025
Le radar 2025 pour préparer votre roadmap
Tech Trends 2025 : prenez le pouls de la tech avec OCTO Pulse
« Software Engineering & Architecture » - Tech Trends 2024
Le Retrofit de la Gen AI dans vos applications