Le métier de développeur est un métier en constante évolution, c’est sa plus grande force et c’est ce qui explique que la perception de notre métier et de ses missions est souvent difficile à appréhender.

Tout d’abord, il faut savoir que : “les développeurs ne sont pas spécialistes de la réparation d’imprimantes et encore moins d’imprimantes wifi”. Plus sérieusement, il est important de garder en tête que notre mission ne se limite pas à écrire des lignes de code pour mettre en place des idées et concepts inventés par d’autres. Cette vision de notre travail est réductrice et problématique puisqu’elle nous place dans une position de simples exécutants, ce qui est totalement incohérent avec notre quotidien.

Oui, nous sommes des créatifs.

🎨 Des processus créatifs

Prenons quelques secondes pour réfléchir à ce qu’est un développeur, les meilleures explications étant les plus courtes, nous pouvons partir d’un simple constat.

Un développeur est une personne qui imagine des solutions simples pour répondre à des problèmes et besoins, parfois complexes.

Il est important de garder en tête que, notre rôle principal est d’imaginer, d’inventer et d’innover. Pourquoi ? Simplement parce que si la solution existe déjà vous n’avez alors pas besoin de nous. Une fois cette idée acceptée, il ne reste plus qu’à venir nous voir avec un problème et à nous inviter à participer aux étapes de création. Notre premier réflexe sera alors de commencer par chercher de l’inspiration afin de mettre sur pied une réponse fonctionnelle. Lors de cette étape, notre objectif est d’explorer et de découvrir le plus de pistes possibles. Une fois les possibilités devant nous, il ne nous reste plus qu’à les combiner ou enrichir des solutions existantes pour répondre le plus efficacement et simplement au problème.

💡 L’architecture, la base de l’innovation

Trop souvent sous-estimée, l’architecture est probablement la partie la plus importante lors du développement de nos idées. De prime abord, ce temps peut paraître excessif ou superficiel mais celui-ci est clé lors de développements complexes. Elle va permettre d’aligner toutes les parties prenantes du projet sur la même vision. Elle va également nous donner une vue macro des fonctionnalités ainsi que des dépendances avec les différents éléments externes au projet. Cette prise de recul assure la conformité avec le parcours utilisateur et met en évidence les éventuels dysfonctionnements de celui-ci.

Le fait de poser l’architecture va également nous permettre de planifier les échéances plus efficacement. Si le périmètre est trop grand, cet aperçu global nous permettra de trouver les simplifications les plus adaptées.

D’un point de vue très réaliste, il est souvent déroutant de prendre du temps sur cette partie lorsque nous n’en avons pas l’habitude. Cependant elle a l’avantage de permettre à tous d’échanger, de mettre en avant différents points de vue et de partager les responsabilités. Il faut néanmoins garder en tête que cette méthode n’est pas magique. Le schéma de cette architecture ne contiendra pas toutes les réponses et sera probablement amenée à évoluer durant les développements puisqu’elle se base sur des hypothèses.

👀 Les POC, quand le test est la clé du savoir

Afin de limiter les risques liés aux hypothèses, le plus simple est encore de les tester. Pour ce faire nous mettons en place des POC (Proof of Concept). Leur objectif est de produire une version expérimentale d’une fonctionnalité afin de déterminer la faisabilité de l’idée.

Nous connaissons tous ce moment très délicat où l’incertitude est tellement grande que nous ne savons plus par quel angle attaquer le sujet. Lorsque c’est possible, il est parfois plus simple d’arrêter les discussions et de passer à une phase pratique.

L’idée n’est pas de produire quelque chose à livrer en production mais bien de pouvoir déterminer la complexité et les possibles risques d’une idée. Que le POC soit une réussite ou non, nous en tirons toujours un enseignement. De plus, en cas d’échec ou de problème critique, c’est souvent un argument non négligeable pour aider le client et l’équipe à envisager une autre piste pour répondre à son problème.

Le point le plus délicat avec ces prototypes est qu’il est important de trouver le bon équilibre entre le temps investi et les réponses apportées.

🚀 L’automatisation, pour se libérer l’esprit

Notre plus gros problème en tant que développeur est le temps. Si nous pouvons aujourd’hui consacrer du temps à de l’expérimentation et de la conception, c’est également parce que nous avons travaillé à l’amélioration de notre quotidien. Le temps que nous passons à déployer, tester et débugger notre code a été automatisé et optimisé, autant que possible, pour nous permettre de nous concentrer sur les tâches pour lesquelles nous avons une vraie valeur ajoutée.

De la mise en place d’environnement Docker et de leurs orchestrateurs, en passant par l’optimisation de notre workflow Git et de la code review, les analyses de code statiques et le déploiement via des pipelines GitLab, nous saisissons toutes les opportunitées pour simplifier notre quotidien. Bien évidemment, toutes ces améliorations ont commencé par un simple POC, puis avec le temps et les retours d’expérience, ont été corrigés, nettoyés et enrichis au plus grand plaisir de nos équipes.

Nous avons donc grâce à notre créativité mis en place une véritable expérience développeur.

💪 Une créativité à partager

Finalement nous nous sommes rendu compte que grâce à toute cette créativité nous avions parcouru un long chemin. Mais il nous est impossible de tout résumer en quelques lignes. Nous nous retrouvons donc dans notre prochain article pour partager avec vous nos expériences et découvertes.