De l’architecture intérieure au développement web, plus de similitudes qu’on ne le croit

Adrien Anelli
Oct 17 · 9 min read

Cela fait maintenant plus d’un an que j’ai quitté mon ancienne profession d’architecte d’intérieur et que j’ai choisi de me reconvertir dans le domaine du développement web.

« Mais… ça n’a rien à voir ?! »

Vu de loin ça semble très différent mais je pense que ça ne l’est pas tant que ça. Certaines compétences peuvent être réutilisées d’un domaine vers l’autre, et c’est ce qui m’a aidé à prendre un nouveau départ comme développeur chez Doctolib.

Ma rencontre avec le code

J’aime apprendre, construire des choses, bricoler et bidouiller. J’ai été menuisier avant d’être architecte d’intérieur, et j’ai toujours eu une fascination pour la technologie, la science, la robotique… Je suis aujourd’hui l’heureux propriétaire d’une imprimante 3d qui me permet de donner libre court à mes expérimentations.

Parmi mes expérience professionnelles, j’ai été associé avec trois personnes dans une entreprise d’architecture intérieure. Être à la tête d’une petite entreprise c’est aussi savoir toucher à tout. Ayant cet attrait pour la technique, j’ai pris en charge le réseau et l’infrastructure de données.

Le site web fut l’étape suivante. De façon progressive, j’ai commencé sur un CMS pour en arriver au site sur mesure hébergé chez OVH. C’est à cette période que j’ai touché au développement web pour la première fois. Comme une grande partie de ceux qui font leurs premiers pas dans le domaine, j’avais cette idée reçue que le développement est intimement lié aux mathématiques…

« Pour coder il faut un doctorat de mathématique »

Vous vous en doutez, il n’est pas nécessaire d’être un crack en mathématique pour apprendre à coder. Je ne vais pas mentir, il y a des mathématiques mais la notion de base c’est tout de même une suite d’action logiques comme l’illustration ci-dessous.

Du code en autodidacte

J’ai rapidement pris goût à la programmation car j’aime la logique (que Wikipédia définit comme signifiant à la fois « raison », « langage » et « raisonnement »). Ma reconversion professionnelle dans ce domaine est donc venue très sérieusement sur la table quand j’ai voulu quitter mon ancienne activité.

J’ai commencé par de la formation en ligne, suivi le batch #120 du Wagon à Paris, puis réalisé des missions de développeur web freelance avant d’être embauché chez Doctolib. C’est aujourd’hui une grande chance que de pouvoir évoluer et apprendre au milieu de développeurs de talents. Être chez Doctolib c’est participer à un beau projet qui valorise l’humain et ambitionne de révolutionner le domaine de la santé.

De nombreuses similarités

Ce dont j’ai pris conscience pendant ma reconversion, c’est la similitude des pratiques et façons de faire entre l’architecture intérieure et le développement. J’ai rapidement eu une sensation de déjà vu, en tirant des parallèles avec mes expériences passées. Dans l’une ou l’autre des disciplines, il y a toujours un problème à résoudre, une situation à améliorer, un nouvel état à atteindre. Et toutes ces phases s’organisent dans un projet.

Comprendre l’existant

En architecture comme en développement, on doit saisir tout ce qui nous environne avant de nous lancer, d’autant plus si le projet se base sur un existant :

  • En architecture : rechercher l’histoire du lieu, les traditions et la culture dans lesquelles s’implante le projet, les contraintes liées au terrain ou à la législation, l’environnement, la situation, l’exposition…
  • En développement : quels technologies et langages, quel motif d’architecture logicielle sont déjà en place sur des fonctionnalités similaires, quelle stratégie de déploiement, monolithe ou micro service, hébergement, tests…

… et assimiler l’existant

Comme l’expérience a tendance à le confirmer, l’ancien est souvent plein de surprises. On peut faire des parallèles comme par exemple avec l’utilisation de mauvais patterns dans le code qui équivaut à des malfaçons en architecture. Une documentation lacunaire ou inexistante d’un côté, ce sont des plans approximatifs ou absents de l’autre. Ou bien encore une mauvaise architecture d’application pour des problèmes de fondations et de structure. Par contre, bien que la dette technique soit un frein dans le code, c’est le coeur du travail lorsqu’on intervient sur de l’existant en architecture.

« Ahhhhh, les charmes de l’ancien. »

L’inattendu mène à des modifications, des reprises, des ajustements, voire même des bouleversements de projet ou des changements de stratégie. Dans les deux disciplines ce genre de situation génère du retard et fait augmenter les coûts. Le projet pourra même pâtir de ce genre de déconvenue, le budget prévu pour la suite et le temps restant avant la date de livraison ont diminué, il peut être nécessaire de couper dans le projet pour que la satisfaction soit tout de même au rendez-vous.

Certaines choses sont très coûteuses à changer mais pour d’autres le changement est plus facile, voire évident. Il est important de savoir où sont les postes de dépense prioritaires, ceux qui auront le bon ratio impact/coût :

  • Archi : Il est plus aisé de modifier un agencement menuisé, de changer du mobilier ou encore d’apposer de la couleur que de déplacer des cloisons ou d’ouvrir un mur porteur.
  • Code : Dans une codebase vaste, il est souvent plus facile de développer une feature “autonome” que de modifier du code existant ayant potentiellement de multiples dépendances.

Recueillir les besoins

À cette analyse du contexte s’ajoutent les attentes du client. En architecture intérieure comme en développement, il est nécessaire de définir clairement les attentes en terme de fonctionnalités, que ce soit des espaces ou des features, ainsi que les qualités de ces fonctionnalités (grande, petite, quelle destination, fréquence d’usage…). On peut par exemple avoir un cadre précisant l’esthétique attendue (couleur et ambiance, graphisme et animations), et plus généralement le budget et les délais.

Le schéma est un bel exemple d’outil partagé utilisé pour définir des besoins : lier des espaces, des tables de bases de données ou des machines, c’est finalement décrire les relations entre des fonctionnalités et/ou des usages. La proximité est plus ou moins impérative, certaines fonctions ou certains usages sont indispensables (un serveur, des wc), d’autres sont publics ou privés…

Plus que de l’exécution

L’architecte d’intérieur ne transforme pas seulement les souhaits de ses clients en plans et projets, il a également un devoir de conseil.

« L’oeil du pro qui va penser à ce à quoi le client n’a pas pensé »

Je pense qu’il y a une similarité dans le domaine du développement. Par exemple, un client n’a pas forcément une idée de la technique nécessaire et adaptée pour mettre en oeuvre son projet. Ou bien il a une idée, mais ce n’est peut-être pas la plus adaptée.

Dans les deux disciplines, les connaissances et l’expérience permettent au professionnel d’identifier les points durs et incontournables, les dépenses primaires, de conseiller sur des points auxquels le client n’a pas pensé, la technique la plus adaptée, les ressources nécessaires… etc. Le client pourra ainsi faire des choix éclairés.

Ce devoir de conseil est écrit dans le code des devoirs professionnels de l’architecte d’intérieur, et côté code, Robert C. Martin (Uncle Bob) a suggéré un code d’éthique lisible sur The Clean Code Blog qu’il a intitulé The Obligation of the Programmer.

Chez Doctolib, ne pas être un simple exécutant se traduit au quotidien dans la façon dont le code est écrit et l’impact sur la codebase, mais aussi par ce qu’on appelle le tech-holdering : chaque développeur est responsable d’un projet à tour de rôle. C’est lui qui a la tâche de cadrer le projet, ses ressources, ses délais, et de déceler les points bloquants pour que tout se déroule au mieux.

Esquisser la vision

Il est l’heure de proposer une réponse, de donner forme à ce projet pour pouvoir partager sa vision. Il faut permettre à son interlocuteur de se projeter et d’appréhender les contours de ce qui est proposé.

Architecture :

  • Présentation concept et storytelling
  • Carnet de plans d’exécution
  • Carnet de prescriptions
  • Descriptif technique

Développement :

  • Présentation concept et storytelling
  • Mockup designer
  • Cadrage technique

Il y a une grande similarité dans les documents de présentation et de référence. Une partie fait la part belle au visuel pour imager et décrire le projet et ses ambitions, une autre partie plus technique est destinée à guider et cadrer la réalisation, spécifier les besoins techniques, humains et matériels, et définir le planning prévisionnel.

Construire le projet

Construire le projet est un mélange de choix étayés, de décisions basées sur l’expérience, mais aussi d’une partie d’empirisme. Essais, retours en arrière, le fonctionnement par itérations, est applicable aux 2 domaines.

  • On part de l’idée, du besoin, on esquisse, schématise, la ligne directrice se dessine.
  • On évoque les différents moyens pour arriver au résultat escompté. Quelles solutions développer ?
  • On propose grâce à des mockup, schémas, plans, storytelling
  • On sélectionne, on teste, on procède à des ajustements, une des autres solutions qui ont été évoquées est peut-être mise à l’épreuve, on en combine éventuellement plusieurs et on avance…

Que ce soit dans le code ou en architecture intérieure, la technique n’est pas une fin en soi, elle est l’outil qui permet d’atteindre l’objectif. La qualité de mise en oeuvre de la technique garde le même enjeu majeur pour aboutir à une réalisation pérenne.

Tech Life Mail Letter Banner
Tech Life Mail Letter Banner
Find out more about Tech Life at Doctolib

Les différences qui m’ont marqué

La notion du temps

Le travail a le même but, matérialiser une idée, un concept, créer quelque chose, mais le rythme auquel il se déroule est un point de divergence. Le temps qui s’écoule entre le challenge d’un nouveau projet et la satisfaction de l’avoir relevé est bien plus long en architecture. Du début d’un projet à sa concrétisation, il n’est pas rare qu’une année voire plus se soit écoulée. Cela dépend bien sûr de la taille du projet, un appartement 2 pièces demande moins de temps qu’un hôtel mais on peut tout de même faire une moyenne.

Le code a ce côté satisfaisant du retour sur investissement à plus court terme. Le fonctionnement par features permet de voir se concrétiser le projet très rapidement, en quelques semaines voire quelques jours.

Sur un gros chantier comme un hôtel on pourrait aussi travailler par étage mais le résultat se ferait quand même attendre au delà de quelques mois.

Projection

Si du code peut être testé, utilisé en cours de développement, à l’évidence on ne peut habiter des plans, des maquettes ou encore des 3d. Les utilisateurs se projettent donc de manière différente et les retours ainsi recueillis pour l’itération sont fondamentalement différents. Dans le code, ils se basent sur une expérience vécue, et plus fiable encore, sur les données recueillies lors de l’utilisation. Mais en architecture intérieure les retours sont le fruit d’une expérience projetée, de ce que l’on aura réussi à imaginer, entrevoir dans la présentation de l’architecte d’intérieur.

L’architecture intérieure touche également des sujets plus intimes où des convictions et des goûts sont généralement déjà établis : habiter est un quotidien, tout comme manger, et chacun sait si la courgette lui plaît ou non.

Conclusion

Être architecte d’intérieur à notre époque, c’est beaucoup de temps passé derrière un écran et un clavier. Je n’ai donc pas été effrayé en envisageant de changer pour un métier où l’on passe énormément de temps sur ordinateur.

« Des points de repère »

Je retrouve dans le développement web les caractéristiques que j’aimais dans mon ancienne profession : construire des choses qui répondent à des problématiques concrètes, être utile, pouvoir améliorer le quotidien de l’utilisateur final. En ajoutant les compétences de logique, d’observation, d’analyse, ou encore de construction d’un projet, transposables d’une discipline à l’autre, je me suis rapidement senti à l’aise avec le code. Ajoutez à cela la philosophie de l’Open Source et les valeurs de partage des connaissances et je suis un homme heureux, non seulement dans mon nouveau métier, mais aussi chez Doctolib.

https://about.doctolib.fr/careers/

Doctolib

Pour un système de santé plus humain, efficace et connecté

Thanks to Benoit Lafontaine and Hugo Chevalier

Adrien Anelli

Written by

Doctolib

Doctolib

Pour un système de santé plus humain, efficace et connecté

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade