[!NOTE] TL;DR : Concevoir des systèmes modulaires et parfaits sur le papier est gratifiant, mais c’est un piège psychologique. Face aux enjeux d’une intégration SAP complexe lors de mon alternance, j’ai compris que la sur-ingénierie est souvent un bouclier pour retarder le moment de tester son code dans le monde réel. Aujourd’hui, je combine la rigueur de l’architecte pour la conception avec l’agilité des MVP (souvent accélérés par l’IA) pour l’exécution.
Si vous me demandez ce que j’aime le plus dans le développement, je vous répondrai probablement : concevoir des systèmes modulaires. J’aime quand le chaos se transforme en ordre. Quand chaque micro-service, chaque script Python, chaque requête SQL a un rôle précis dans une architecture globale, prévisible et élégante.
C’est ce que j’appelle mon côté “Architecte”. L’architecture de systèmes complexes répond chez moi à un impératif d’ordre : il s’agit de rendre le monde structuré pour le sécuriser. Mais pendant mon alternance, j’ai découvert le côté obscur de cette passion : le piège de la sur-ingénierie.
Le paradoxe de la préparation
Face à des architectures critiques qui devaient automatiser des flux de données industrielles, mon premier réflexe a été de concevoir la solution parfaite sur le papier. Je voulais qu’elle soit irréprochable, capable de gérer des cas d’usage qui n’existaient même pas encore, et modulable à l’infini.
C’est la marque d’un artisan consciencieux, mais c’est aussi un excellent bouclier inconscient.
Pourquoi ? Parce que tant que votre code reste dans votre environnement de développement local, il est parfait. Il n’a pas encore affronté la réalité brutale des serveurs de production, des utilisateurs imprévisibles ou des bizarreries des données historiques. Chercher la perfection immédiate et l’anticipation absolue de tous les cas d’erreur mène tout droit à la paralysie par l’analyse.
L’exigence technique devient, malgré nous, une excuse pour retarder le test décisif face au marché ou à la production.
Le coût cognitif de l’excellence
À force de vouloir tout concevoir avec une qualité absolue, on refuse parfois la facilité d’un déploiement rapide ou d’un code “sale mais qui marche”. Or, dans un contexte d’entreprise où la livraison de valeur prime, cette obstination a un coût cognitif lourd. Le perfectionnisme devient un tyran intérieur qui alourdit la charge mentale. On porte le poids d’un projet qui ne voit jamais le jour.
J’ai dû accepter une vérité souvent difficile à avaler pour notre ego de développeur : une architecture imparfaite mais livrée et testée est toujours supérieure à un chef-d’œuvre confiné en local.
L’équilibre : Rigueur en conception, pragmatisme en exécution
La solution n’a pas été de baisser mes standards de qualité, mais d’adapter ma méthode pour contourner ce biais psychologique. J’ai commencé à compartimenter les approches :
- Garder la rigueur absolue de l’Architecte pour la phase de conception. Dessiner les plans, comprendre les flux de données, assurer la sécurité logicielle.
- Adopter l’agilité (et souvent l’IA) pour l’exécution d’un MVP rapide. L’utilisation des agents d’intelligence artificielle m’a permis de générer rapidement des Produits Minimum Viables. Au lieu de passer des jours à écrire un code parfait à partir de zéro, j’ai pu me concentrer sur mon rôle d’assembleur et valider mes concepts en conditions réelles beaucoup plus vite.
Bilan
Aujourd’hui, je vois toujours le code comme le pont ultime entre le numérique et le monde physique (notamment à travers l’IoT). Mais j’ai compris que ce pont n’a pas besoin d’être construit en acier trempé dès le premier jour de chantier. Il a d’abord besoin d’être traversable. C’est sans doute l’une des plus belles leçons de maturité technique de cette alternance.