Actuellement en recherche de poste, il est plusieurs points qui me font considérer son attrait.

Le minimum requis

Ayant maintenant un certain nombre d’années d’expérience, j’ai un profil orienté “consultant” plutôt que “simple exécutant” et je m’épanouis dans un environnement qui contient au moins tous ces critères :

• Amélioration continue : les propositions de changement, que ce soit dans les pratiques de développement ou l’organisation de l’équipe, sont a minima entendues et discutées. Rien n’est imposé par “cargo cult” (ex : “on a toujours fait comme ça”).
• Craft et bonnes pratiques : le code est testé, il y a une vraie intégration continue (les branches ne durent pas plusieurs semaines), et les livraisons en production se font fréquemment, du type plusieurs fois par mois. Livrer en production n’implique pas une phase de “non régression” longue, coûteuse et stressante, tout se fait sereinement.
• Agilité : on parle d’une véritable façon de fonctionner où l’IT est au service du métier et s’adapte aux changements. Donc les discussions avec les expert·es métier se font régulièrement et les process changent en fonction du besoin, la communication est productive. Dans un esprit d’amélioration continue, des cérémonies de rétrospective ont lieu régulièrement et des actions constructives sont mises en place.
• DevOps : les équipes système (expertise Azure, DBA, responsables sécurité, etc…) sont joignables facilement et les relations saines avec les équipes de développement. Le suivi de production s’effectue au sein des équipes, tout le monde participe et ce n’est pas vu comme une corvée.
• Télétravail au moins 3 jours par semaine et le présentiel a du sens. Depuis 2020, j’ai pu constater la nette augmentation de ma productivité et celle de l’équipe en général grâce au télétravail.

Le poste idéal

Pour aller plus loin, voici ce que je souhaite idéalement en incluant évidemment les points précédents :

• Bienveillance et non-toxicité de l’équipe et du management. Je ne crois pas dans la notion bizarrement répandue de “dictateur bienveillant” qu’on fait parfois porter aux tech leads. C’est à mon avis une approche qui se révèle rapidement toxique et contre-productive ; je lui préfère celle du référent, à la fois plus humble, plus ouverte et nettement plus en adéquation avec ma personnalité.
• Diversité et inclusivité de l’environnement. Une équipe avec des profils divers amènera plus de richesse et de succès qu’une équipe composée des mêmes profils. La tech est un milieu très masculin, peu inclusif et trop rebutant pour de nombreuses personnes ne correspondant pas au stéréotype “homme blanc hétéro cisgenre”. Je souhaite contribuer à changer cela.
• Approche “test first” : indispensable pour se poser les bonnes questions dès le début du développement et passer le temps qu’il faut dans l’espace du problème au lieu de sauter directement dans l’espace de la solution.
• Agilité : y a-t-il du travail en flux ou est-ce un cycle en V (même camouflé en sprints) ? Les dates et les deadlines sont-elles des notions importantes ? Par exemple, CI et CD ne sont pas des mots vides de sens, ils impliquent des pratiques importantes comme une synchronisation et une livraison régulières et fréquentes dans la branche principale, idéalement en utilisant le (trunk-based development. Derrière, une batterie de tests automatiques vérifie la non-régression en quelques minutes et une livraison en production est possible plusieurs fois par jour sans stress.
• Temps partiel : ayant travaillé à 80% entre avril 2020 et avril 2024, j’ai pu voir les bénéfices du travail à temps partiel sur ma productivité et ma communication.
• Réactions en cas de crise : l’absence de micro-management est nécessaire, ainsi qu’une bonne communication sur un canal dédié ; la mise en place d’actions après crise (discussions et réflexion long terme) est un atout important.
• Suivi de production proactif : on a les outils pour regarder l’état de la production en temps réel et pouvoir agir rapidement avant tout retour utilisateur ou des équipes métier. C’est facilité par l’approche DevOps vue dans la section précédente.
• Dans un contexte legacy : appui voire impulsion du management pour en sortir. Malgré ses défauts, le code legacy remplit un besoin métier ; il est donc précieux pour le métier mais il faut s’y attaquer via des actions de fond comsommatrices de temps et de budget. Je peux être moteur sur ce genre de sujet mais je ne souhaite pas être seul dans ce combat.

Bien sûr on peut discuter et débattre de chacun des points mais ma vision du poste idéal les contient tous.