Cette page s'adresse aux interlocuteurs techniques : les technologies employées, les règles d'ingénierie appliquées sur chaque projet, et les choix que j'écarte avec les raisons correspondantes.
Relevé sur les 22 dépôts de mon poste disposant d'un historique git
Méthodes de test recensées sur mes sept projets les plus récents
Sur le projet le plus avancé — chaque évolution de schéma est rejouable
Web, API et services, bureau, mobile, temps réel
Ces chiffres proviennent de mes projets personnels et internes, mesurés sur mon poste de travail. Les développements réalisés pour des clients ne sont ni comptés ni décrits ici, pour des raisons de confidentialité.
Compétences
Chacun correspond à des projets effectivement livrés. Ce qui ne figure pas dans cette liste ne fait pas partie des compétences que j'avance.
01
Conception, développement, mise en production et exploitation. Interfaces interactives côté serveur ou côté navigateur selon ce que le projet justifie, communication temps réel, API consommées par des clients tiers.
02
Modélisation relationnelle et couche d'accès aux données écrite entièrement : requêtes paramétrées, interfaces et classes abstraites pour tout ce qui se répète. Aucun ORM ne s'intercale entre le code et la base, sur les petits projets comme sur les gros.
03
Authentification et gestion fine des droits, contrôle systématique côté serveur, cloisonnement strict entre organisations, secrets chiffrés au repos, journal d'audit des actions sensibles, export et suppression des données personnelles.
04
Provisionnement reproductible de machines, services gérés par systemd, orchestration à distance par SSH avec liste blanche de commandes, sauvegardes programmées et restauration éprouvée. Une installation doit pouvoir être rejouée, pas reconstituée.
05
Découpage en couches avec des règles de dépendance vérifiées par des tests qui échouent si on les enfreint. Tests unitaires, tests d'intégration sur base réelle, et décisions d'architecture consignées avec leur date et leur motif.
06
Quand le navigateur ne suffit pas : accès au matériel, travail hors connexion, intégration au poste de travail, synchronisation différée avec résolution de conflits.
07
HTML, CSS et JavaScript écrits à la main quand c'est le bon outil — ce site en est l'exemple : aucun framework, aucune requête vers un service tiers, animations pilotées par canvas et respect du réglage système de mouvement réduit.
08
Import et export de formats hétérogènes, traitements par lots, tâches planifiées, pilotage d'outils externes en ligne de commande, génération de documents. Ces traitements suppriment des manipulations répétitives et les erreurs de saisie qui les accompagnent.
Exigences d'ingénierie
Elles s'appliquent quelle que soit la taille du projet et ne sont pas revues à la baisse selon le budget. C'est ce qui sépare un logiciel que l'on peut faire évoluer d'un logiciel qu'il faut réécrire.
Choix assumés
Ces positions techniques sont argumentées et appliquées par défaut. Elles restent ouvertes à la discussion si votre contexte impose un autre choix.
Une vitrine, une documentation ou une page de présentation n'ont besoin ni d'un moteur de rendu côté client, ni d'un arbre de dépendances qu'il faudra tenir à jour aussi longtemps que le site existe.
Ce site en est la démonstration : HTML, CSS et JavaScript écrits à la main, aucune dépendance externe, aucune requête vers un domaine tiers. Un framework se justifie quand l'application a un état riche à gérer — pas parce que c'est l'habitude.
Charger une police depuis un serveur externe transmet l'adresse IP de chacun de vos visiteurs à une société étrangère. Pour une police de caractères. Le même raisonnement vaut pour les scripts de statistiques, les widgets et les bibliothèques chargées depuis un CDN.
Chaque dépendance externe est une panne possible, une faille possible et une obligation réglementaire de plus. Quand la fonction est triviale, elle est hébergée chez vous.
Un ORM interpose une couche entre le code et la base : il génère des requêtes que le développeur ne contrôle plus, charge souvent plus de données que nécessaire, et rend le diagnostic d'une lenteur beaucoup plus difficile. Ce coût se paie en performance à l'exécution et en temps passé à comprendre ce qui part réellement vers la base.
J'écris donc moi-même la couche d'accès aux données, en SQL paramétré. Les interfaces et les classes abstraites factorisent tout ce qui se répète : on obtient le même confort d'écriture qu'avec un ORM, sans la lourdeur, et le SQL exécuté reste exactement celui qui a été écrit. Cette approche vaut aussi bien pour un outil de quelques tables que pour une base volumineuse.
Avant d'installer une nouvelle version, on doit savoir comment revenir à la précédente, et l'avoir vérifié. Cela suppose une sauvegarde restaurable, des migrations de schéma rejouables et une version précédente conservée.
Cette procédure est fastidieuse à établir la première fois, puis elle fait gagner un temps considérable à chaque mise à jour suivante.
L'environnement de développement n'est pas une preuve. Ce qui compte, c'est une installation reproductible sur une machine vierge, avec une procédure écrite qui a été suivie au moins une fois de bout en bout par quelqu'un d'autre — ou à défaut, rejouée à blanc.
Modes d'intervention
Intégration à une équipe existante sur une durée définie, avec vos outils, vos conventions et votre processus de revue. Je m'adapte à votre socle, je n'impose pas le mien.
Lecture d'un code existant, cartographie de l'architecture, relevé des risques techniques et de sécurité, estimation du coût de reprise. Livré sous forme d'un document exploitable par une direction comme par un développeur.
Un logiciel qui tourne encore mais que plus personne ne maîtrise. Prise en main, remise en état de compilation et de déploiement, documentation de ce qui existe, puis évolution progressive.
De la spécification à l'exploitation, en autonomie. Le mode le plus fréquent : vous décrivez le besoin métier, je livre le logiciel, la documentation et la procédure d'installation.
Discussion technique
Décrivez le contexte et les technologies en place. Vous obtenez un premier avis technique — ou l'indication que le sujet sort de mon champ — avant qu'il soit question de devis.