Architecte logiciel & système

J'endosse le rôle d'architecte logiciel et système lorsque la complexité d'un produit dépasse la simple addition de composants techniques. C'est généralement le cas lorsque plusieurs technologies doivent cohabiter, que le produit est destiné à durer, et que les décisions prises aujourd'hui conditionnent fortement les évolutions futures.

Chez Naept et ID-1, j'ai occupé ce rôle dans des contextes de petites équipes, parfois sans véritable pair technique pour challenger les choix. Mon rôle consistait alors à maintenir une vision globale cohérente, tout en arbitrant en permanence entre complexité, robustesse, coût et délai.

Je ne cherche pas à concevoir une architecture « idéale » ou académique, mais une architecture adaptée à son contexte, capable d'évoluer sans refonte permanente.

Chez ID-1, j'ai par exemple repris un logiciel legacy pour lequel une refonte complète avait été engagée pendant près d'un an. L'analyse du périmètre fonctionnel, de la taille de l'équipe et des choix techniques existants m'a conduit à considérer cette refonte comme irréaliste. J'ai alors orienté le projet vers une modernisation incrémentale, permettant de sécuriser l'existant tout en introduisant progressivement de nouvelles architectures et technologies.

Je porte une attention particulière au découpage fonctionnel et à la clarté des responsabilités. Chez ID-1, certaines fonctionnalités ont été isolées dans des applications distinctes, interconnectées par des API. Il ne s'agissait pas de microservices au sens strict, mais d'une application pragmatique de leurs principes : limiter les couplages et rendre les évolutions indépendantes possibles.

Chez Naept, cette logique s'est traduite par une architecture frontend / API, permettant de proposer une expérience utilisateur fluide, proche d'une application, tout en conservant une structuration claire côté backend.

Un choix marquant a été l'utilisation de ProseMirror comme socle d'édition de texte chez Naept. Ce choix visait à obtenir un contrôle total sur le modèle documentaire et le comportement de l'éditeur, tout en dissociant clairement le rendu visuel de la logique métier. La complexité initiale était assumée, car elle permettait des évolutions futures sans remise en cause profonde de l'existant.

Ce type de décision illustre bien ma manière d'aborder l'architecture : accepter une complexité maîtrisée lorsqu'elle permet d'éviter une dette structurelle à long terme.

Mon approche actuelle est aussi le fruit d'erreurs assumées.

Je privilégie des architectures capables de durer :

Je suis volontairement méfiant vis-à-vis des effets de mode. Un concept pertinent mal appliqué est souvent plus dangereux qu'une solution simple bien maîtrisée.