Ingénierie logicielle
Produire du code vite est à la portée de tout le monde désormais. Ce qui sépare une application qui dure d'une application réécrite dans trois ans, c'est ce qui entoure le code : des exigences écrites pour être exécutées, des décisions tracées, et une qualité contrôlée à chaque commit plutôt qu'à la recette.
Ce qui coûte cher dans un logiciel n'est jamais la première version.
Les organisations consacrent environ trente pour cent de leur budget informatique à gérer la dette technique, et les développeurs passent une part importante de leur temps à la contourner plutôt qu'à construire. Aucune de ces dettes n'a été créée volontairement. Elle s'accumule par des décisions que personne n'a écrites, des exigences précisées à l'oral, et des contrôles de qualité devenus négociables quand la date approchait.
Nous travaillons donc sur ce qui entoure le code. Des comportements écrits sous une forme qui s'exécute, pour que l'écart avec le code se voie tout seul. Des décisions d'architecture consignées avec ce qui a été écarté et pourquoi. Un petit nombre de barrières bloquantes, assez peu nombreuses pour que personne ne les désactive sous pression. Et l'accessibilité comme le poids des pages traités en exigences dès le premier sprint, puisque depuis juin 2025 la directive européenne fait de la première une obligation légale et non une préférence.
Ce que nous faisons
Quatre chantiers, de la première exigence à la dixième année de service.
Concevoir et construire
Des applications web, mobiles et cloud-native, avec une interface conçue avec ceux qui vont s'en servir. Des microservices là où deux rythmes diffèrent réellement, et un seul déployable là où ils ne diffèrent pas.
l'architecture répond à une contrainte, sinon elle n'est pas retenue
- Applications web, mobiles et cloud-native
- Une frontière par domaine, quand les rythmes diffèrent
- Design system et parcours testés avec de vrais utilisateurs
Tenir la ligne de qualité
Un petit nombre de barrières bloquantes au commit : couverture des comportements, vulnérabilités des dépendances, violations d'accessibilité détectables et budget de poids. Assez peu pour qu'aucune ne soit désactivée.
un assistant propose, un ingénieur nommé en répond
- Un test par comportement, qui échoue sans lui
- L'accessibilité vérifiée à chaque commit
- Le code généré relu par un responsable nommé
Auditer et localiser la dette
Des audits de code, de sécurité et de dépendances qui produisent une carte plutôt qu'une note. Ce qui compte n'est pas la quantité de dette, c'est de savoir si elle se trouve là où le métier demande le plus de changements.
la dette s'arbitre avec une estimation en face
- Dette localisée fichier par fichier, pas moyennée
- Croisée avec l'historique des modifications
- Une estimation devant chaque remise en état
Faire vivre et faire évoluer
Un correctif et un évolutif sur la chaîne qui a construit l'application, avec l'accessibilité et le poids mesurés à chaque livraison. Un produit qu'on cesse de mesurer se met à dériver en silence.
l'éco-conception mesurée sur le parcours, pas affirmée
- Correctif et évolutif sur la chaîne de livraison, pas à côté
- Poids et requêtes budgétés, puis tenus
- La dette suivie en tendance, publiée à l'équipe
Ce que vous recevez
Un même projet traverse les quatre livrables ci-dessous : la refonte d'un espace client. Chaque étape dit ce qui est réellement remis, dans l'ordre où il l'est.
Comment on travaille
Cadrer
selon le nombre de parcours et l'état des exigences existantes
- Les comportements attendus, écrits pour être exécutés
- Les exigences d'accessibilité et de poids, chiffrées
- Les barrières bloquantes, peu nombreuses et assumées
Construire
selon la taille du périmètre et le nombre d'intégrations
- Les décisions d'architecture écrites, avec ce qui a été écarté
- Le premier parcours en production, pas en démonstration
- La chaîne qui contrôle à chaque commit
Étendre
selon le rythme du métier et la dette déjà présente
- Le reste des parcours, au même standard
- La dette localisée, chiffrée, arbitrée
- L'équipe interne outillée sur la même chaîne
Faire vivre
engagement de service défini avec vous
- Correctif et évolutif sur la même chaîne
- Accessibilité et poids mesurés à chaque livraison
- La dette suivie en tendance, pas en valeur absolue
Ingénierie augmentée, en partenariat avec Vercel
Adservio et Vercel partagent une conviction simple : livrer vite, sans rien céder sur la performance ni la sécurité. Ce partenariat ancre notre pratique du développement logiciel sur une plateforme de delivery moderne, du commit à la production, en passant par les preview deployments et l'edge.
Concrètement, nos équipes conçoivent et industrialisent des applications Next.js performantes, observables et éco-conçues, augmentées par l'IA à chaque étape : un time-to-market mesurable, une expérience web rapide et une base de code maintenable dans la durée.
Ce que coûte réellement un logiciel
Des produits qui tiennent encore debout
Quarante-deux applications tenues à un standard mesuré
96 % de score d'accessibilité · 42 applications
Un parc applicatif critique utilisé chaque jour par plus de 120 000 agents territoriaux, où une indisponibilité est vue par les utilisateurs avant la supervision, et où l'accessibilité est une obligation légale et non une préférence.
Une instrumentation systématique, des niveaux de service mesurables et une accessibilité suivie livraison après livraison plutôt qu'auditée une fois par an, avec la pratique transmise aux équipes internes.
Un produit où la précision du modèle est la fonctionnalité
96 % de précision du modèle · taux d'erreur 35 % → 1 %
Un relevé dentaire fait à la main, lent et inégal, sur un produit où une lecture fausse n'est pas un défaut à corriger plus tard mais une réponse clinique donnée à un praticien.
Un apprentissage profond intégré au produit plutôt que posé à côté, co-construit avec les praticiens qui l'utilisent, avec la précision mesurée comme un critère de livraison et non comme un résultat de recherche.
Insights & Perspectives
Domain-driven design : principes, patterns et bénéfices
Langage omniprésent, bounded contexts, agrégats et event storming : quand adopter le DDD, et quels bénéfices en attendre raisonnablement.
API Design : REST vs GraphQL et au-delà
Votre API est votre contrat avec le monde. REST a tenu vingt ans, GraphQL a changé les termes, et le choix n'est pas une affaire de goût.
Décisions architecturales logicielles : qui doit être impliqué ?
Andrew Harmel-Law sur la décentralisation des décisions d'architecture : conseil sans permission, ADR, et la confiance que cela demande.
Construisez quelque chose qui tiendra encore dans cinq ans
Des exigences écrites pour être exécutées, des décisions consignées, un petit nombre de barrières qui tiennent, et une dette localisée plutôt que moyennée.
Questions fréquentes
De décisions que personne n'a écrites et d'exigences précisées à l'oral, bien plus que de mauvais code. Environ trente pour cent des budgets informatiques passent à la gérer, et aucune n'a été créée volontairement : elle s'accumule chaque fois qu'une barrière devient négociable sous la pression d'une date.
Seulement là où deux parties changent réellement à des rythmes différents. Découper par écran multiplie les appels réseau sur un parcours qui tient en une transaction, et déplace la complexité du code vers l'exploitation. Une frontière est un coût, et elle doit acheter quelque chose.
Dans les exigences, pas à la recette. La directive européenne sur l'accessibilité s'applique aux services numériques grand public depuis le 28 juin 2025, sur la norme EN 301 549 qui suit WCAG 2.1 niveau AA. Écrite en amont elle coûte des heures ; trouvée à la recette elle coûte une refonte.
En en mettant très peu. Une longue liste de contrôles bloquants saute la première fois qu'une livraison est en jeu, et ne revient jamais. Quatre barrières qui tiennent toujours valent mieux que vingt qui tiennent jusqu'à la première semaine difficile.
Un ingénieur nommé, comme pour n'importe quel autre code. Le volume produit ne change pas qui signe. La revue cesse d'être une formalité précisément parce que la quantité de code qui arrive a augmenté, pas malgré cela.
Non, elle oblige à budgéter le poids et les requêtes comme on budgète la latence. L'essentiel du résultat vient des mêmes leviers qui rendent une page rapide : moins de requêtes, moins de poids transféré, un meilleur cache. L'utilisateur voit un produit plus rapide, pas plus pauvre.
Le cadrage prend 2 à 6 semaines selon le nombre de parcours et l'état des exigences existantes, et produit les comportements exécutables, les exigences d'accessibilité et de poids chiffrées, et les barrières bloquantes. Le premier parcours en production, pas en démonstration, suit en 4 à 10 semaines.