Développeur full stack, architecte de solutions et responsable technique. Voici comment je raisonne, ce à quoi je tiens, et ce que vous pouvez attendre — ou non — si nous travaillons ensemble.
Avant d'être un profil, je suis quelqu'un d'assez têtu.
Cette page n'est pas un CV. C'est ce que je vous raconterais si on avait une heure devant nous — y compris les parties qui ne me valorisent pas particulièrement.
Je n'ai jamais rencontré un projet qui avait échoué à cause du langage choisi. J'en ai vu beaucoup échouer parce que personne n'avait parlé aux gens qui allaient s'en servir.
Ils connaissent le métier mieux que quiconque, et rarement le vocabulaire technique.
Elle a besoin de voir, de décider et de justifier — pas de lire du code.
Elle n'accepte aucune approximation, et ne pardonne pas un modèle de données bâclé.
Les situations où ma combinaison métier, architecture, terrain et production change réellement quelque chose.
Depuis 2021, des missions pour des structures très différentes. C'est la meilleure école que je connaisse : quand vous êtes seul face à un client, vous ne pouvez plus vous cacher derrière une équipe. Vous apprenez à estimer, à dire non, et à livrer.
Développement logiciel et coordination de projet. J'ai découvert que la partie difficile n'était pas technique : c'était de tenir un engagement, de suivre des livrables et d'annoncer un retard avant qu'il ne devienne un problème.
2023 à 2025, full stack sur des plateformes web, des applications métier et des solutions géospatiales. C'est là que j'ai rencontré le foncier, les données drone et PostGIS — et que j'ai compris qu'une carte n'est jamais un simple joli fond d'écran.
Chef du service informatique et drones. Je code encore, mais je passe désormais autant de temps à arbitrer, à faire grandir une équipe et à défendre des choix techniques devant des gens qui ne parlent pas informatique.
La partie la plus difficile de ce métier n'a jamais été le code.Aucune de ces phrases n'est gratuite : chacune m'a coûté au moins un projet difficile avant que je la comprenne.
Un portfolio ne montre que les réussites. Voici l'autre moitié — elle vous fera gagner du temps.
Si je pense qu'une demande va contre l'intérêt du projet, je le dis. Une fois. Ensuite, si la décision est maintenue, je la mets en œuvre correctement — mais je l'aurai dit.
Je fais des interfaces claires, cohérentes et utilisables. Pour une identité visuelle forte et un vrai travail graphique, il faut quelqu'un dont c'est le métier — et je travaille bien avec ces gens-là.
Je privilégie les projets où la qualité de la solution compte autant que sa mise en production. Je compte donc le temps de l'analyse, des tests, du déploiement et de la reprise — un devis qui oublie ces lignes n'est pas moins cher, il est incomplet.
Face à un métier nouveau, je prends le temps d'observer avant d'annoncer une date. C'est plus lent au début, et nettement plus rapide à l'arrivée.
Ce n'est pas un défaut, mais autant le dire : je vais revenir vous demander si les gens s'en servent vraiment. Et je serai déçu si la réponse est non.
Je ne vais pas vous annoncer « +50 projets livrés » ni « 100 % de clients satisfaits ». Ces chiffres ne coûtent rien à écrire et ne prouvent rien.
Ce que je peux prouver, en revanche, se vérifie en une conversation : demandez-moi de vous expliquer une décision d'architecture que j'ai prise, pourquoi je l'ai prise, et ce que j'en referais autrement aujourd'hui. Vous en apprendrez davantage en dix minutes que dans n'importe quel compteur animé.
On ne travaille pas avec un ensemble de compétences. On travaille avec quelqu'un.
C'est un vrai défaut et j'y travaille. Mais mes meilleures idées d'architecture ne me viennent jamais devant l'écran : elles arrivent en marchant, ou au milieu d'une conversation qui n'avait rien à voir.
Droit foncier, organisation du travail, logistique, agriculture. Ce n'est pas de la culture générale décorative : c'est exactement ce qui me permet de comprendre vite le métier d'un client.
Former une équipe, rendre une notion technique compréhensible pour une direction, écrire une documentation que quelqu'un lira vraiment. C'est la partie du métier dont je ne me lasse pas.
Je préfère un logiciel simple qui fonctionne sur le terrain à une architecture parfaite que personne n'utilise.
Un point régulier, des versions qu'on peut essayer, des mauvaises nouvelles annoncées tôt, et une explication compréhensible de chaque choix technique. C'est le minimum que je me dois.
Saadoukou