Une ESN normande, en télétravail

Une équipe d’ingénieurs normands, en télétravail

Popixa n’a pas de bureau. Nos ingénieurs vivent en Normandie et travaillent depuis chez eux, et nous préférons l’écrire que le laisser deviner. Ce n’est pas une organisation par défaut ni une conséquence d’une époque : c’est ce qui nous permet de recruter des ingénieurs expérimentés là où ils vivent, plutôt que là où un bail nous aurait fixés.

Cet ancrage n’est pas décoratif. Il change qui nous sommes capables d’embaucher, la manière dont nous parlons des projets, et le fait que nous connaissions de l’intérieur les contraintes des entreprises d’ici — celles qui n’ont pas de direction technique à quinze personnes et qui doivent arbitrer entre recruter, sous-traiter et attendre.

Un ingénieur qui reste sur une mission en connaît l’historique — les arbitrages passés, les raisons d’un choix technique qui semblerait autrement arbitraire, les zones fragiles du code que personne n’a documentées. Cette continuité n’est pas un supplément d’âme : elle évite la reconstitution de contexte à chaque rotation, qui coûte cher et se paie en bugs réintroduits. Recruter localement, c’est aussi recruter pour rester — un ingénieur qui construit sa vie en Normandie n’a pas de raison de partir dans dix-huit mois vers un siège social ailleurs.

Ce que le télétravail change, et ce qu’il ne change pas

Ce qu’il ne change pas : la façon de travailler. Un binôme d’ingénieurs-consultants conçoit et développe, l’IA prend le code répétitif, et chaque ligne est relue par un ingénieur nommé. Le code vit dans votre Git, pas dans le nôtre — auditable pendant la mission et après. Rien de tout cela ne dépend d’un lieu.

Ce qu’il change : nous ne viendrons pas nous asseoir dans vos locaux le lundi matin. Si votre modèle de collaboration repose sur une présence physique régulière, nous ne sommes pas le bon prestataire, et il vaut mieux le savoir avant de signer qu’après.

Ce qu’il change aussi, dans l’autre sens : le fuseau, la langue et les jours fériés sont les vôtres. Une réunion se cale sans décalage horaire, une question posée en fin d’après-midi n’attend pas le réveil d’un autre fuseau, et personne ne vous explique un arbitrage technique dans un anglais approximatif.

Concrètement, la semaine s’organise autour de points courts et réguliers plutôt que d’une présence continue : un point d’avancement en visio, le reste en asynchrone — un ticket, un message, une revue de code commentée. Les décisions qui comptent ne se prennent pas en réunion pour la forme ; elles se prennent au clavier, tracées dans l’outil où le projet vit, pas dans le compte-rendu d’une réunion à laquelle vous n’étiez pas. Une question urgente ne remonte pas à travers un chargé de compte qui relaie à un ingénieur qu’il ne connaît pas lui-même : elle va directement à celui qui a écrit le code, parce que c’est la même personne du premier jour au dernier.

Ce sur quoi nous intervenons

Quatre domaines : le développement sur mesure, les tests et la qualité, la documentation technique, et la reprise d’applications héritées. Ils sont détaillés sur la page des domaines d’intervention — ici, ce qui compte est ce qu’ils recouvrent dans le tissu économique régional.

La Normandie n’est pas un désert numérique, mais son tissu est fait d’industrie, de logistique, de santé et d’assurance bien plus que de start-up. Les besoins qui nous arrivent ressemblent à ça : une application métier écrite il y a douze ans dont l’auteur est parti, un outil interne qui tient sur un tableur et qui n’aurait jamais dû, un produit qu’il faut sortir avant de savoir s’il trouvera son marché.

Nous intervenons en Normandie — à Rouen, à Caen, au Havre — comme ailleurs en France, sans agence dans aucune de ces villes.

Le développement sur mesure couvre le plus souvent un outil interne devenu trop important pour rester géré à la main, ou une brique manquante entre deux logiciels métier qui ne se parlent pas. Les tests et la qualité arrivent quand une application tourne depuis des années sans filet, et qu’un changement mineur fait craindre une régression que personne ne saurait détecter à temps. La documentation technique comble ce que l’auteur parti n’a jamais écrit — schéma de données, décisions d’architecture, procédure de déploiement — pour que l’équipe restante ne dépende plus d’une seule mémoire. La reprise d’applications héritées, enfin, consiste à comprendre un système avant d’y toucher : lire ce qui existe, cartographier les dépendances, avant la moindre ligne modifiée.

Ce que nous ne promettons pas

Pas de proximité physique. Pas de rendez-vous à recevoir : nous n’avons pas de bureau. Pas de commercial qui passe. Si vous cherchez une ESN qu’on peut visiter, la réponse honnête est que ce n’est pas nous.

Nous ne promettons pas non plus de connaître votre métier mieux que vous. L’IA écrit vite et se trompe avec assurance ; nos ingénieurs cadrent, arbitrent et répondent. C’est cette frontière-là que nous tenons, et c’est la seule chose que nous vendons.

L’absence de bureau ne nous dispense de rien. Le code que nous livrons vit dans votre Git, avec un historique qui dit qui a écrit et qui a relu chaque ligne — vous n’avez pas à nous croire sur parole, c’est vérifiable chez vous. Et si un incident bloque votre production, il est pris en charge sous 4 h ouvrées, par le même ingénieur nommé qui a construit — pas par un numéro de ticket anonyme.