Mon expérience de CTO chez Spacefill de 2019 à 2023

J’ai rejoint Spacefill parmi les tout premiers employés. En tant que CTO, j’étais responsable des choix techniques, du recrutement et du management des développeurs, le tout en étroite collaboration avec le CPO — cofondateur.

J’ai commencé par développer une marketplace de stockage en entrepôt, ensuite une web application de type OMS (Order Management System) et une Web API publique.

Cette Web API publique permettait de communiquer avec des applications de l’univers logistique, du type WMS, OMS, TMS, ERP.

J’ai travaillé sur l’implémentation et de déploiement de nombreuses intégrations dites “EDI”, concrètement des programmes (de type worker) de transfert d’information d’un système à un autre — lecture de données via Web API ou via des fichiers exposés par le protocole FTP, puis transformation de ces données et pour finir, écriture de ces données sur une Web API ou à nouveau dans des fichiers via le protocole FTP.

Quelques-unes de mes activités de manageur :

  • Recrutement : rédaction et publication des fiches de postes, définition des critères de rémunérations, sourcing de candidats, tenue d’entretiens de recrutement , suivi d’“onboarding” des nouvelles recrues…
  • Discussion 2 fois par mois en tête-à-tête avec chaque membre de l’équipe tech et produit — généralement sous la forme de walking meeting — afin de garder du lien, recevoir du feedback, comprendre le ressenti de chaque personne, partager ma vision, répondre aux questions, partager des conseils.
  • Proposer des mises à jour des process de développement ou de management produit… pour répondre aux besoins du produit, aux difficultés et aux idées des développeurs. Mon objectif était de créer une direction commune tout en essayant d’atteindre un certain niveau de consensus.

Voici ce à quoi ressemblaient mes activités de développeur :

  • Coder en React et un peu en Node.JS ;
  • Écriture de query et mutation GraphQL ;
  • Faire évoluer la base de données PostgreSQL :
    • modélisation des données (tables) ;
    • écriture de migration de données ;
    • écritures de triggers en pgSQL.
  • Écriture de fonctions PL/pgSQL pour implémenter des Queries ou Mutations GraphQL customs ;
  • Rédiger, améliorer et commenter des issues ;
  • Prendre soin de mes Merge Requests afin de les pousser le plus rapidement possible en production ;
  • Faire de la revue de code ;
  • Écrire des spécifications techniques et parfois participer aux specifications produits ;
  • Guider les nouveaux développeurs ;
  • Améliorer continuellement la documentation du projet ;
  • Écrire des tests UI ;
  • Des interventions ponctuelles DevOps (Terraform / Ansible) ;
  • Écrire, faire évoluer quelques scripts Python.

Technologies utilisées :

Quelques informations supplémentaires concernant le fonctionnement du backend :

L’API GraphQL était auto-générée par Postgraphile, qui est un serveur OpenSource écrit en NodeJS et se connecte “au-dessus” de PostgreSQL.
Cela ressemble à Hasura, Supabase ou Firebase.
Les paramétrages, adaptations pouvaient se faire soit via des commentaires sur des ressources PostgreSQL (tables, champs), soit via la création de Views ou de functions PostgreSQL.
Les tâches qui ne pouvaient pas être effectuées par PostgreSQL, comme par exemple l’envoi de mails, la génération de PDF… sont effectuées par un “service worker”, avec du code NodeJS “classique”.

Méthode de travail

Nous essayions autant que possible de suivre la méthode Scrum.

Ce qui était mis en place :

Nous utilisions GitLab pour :

Tout changement dans le code ou la documentation passait par une Merge Request avec un process de review.