Développement sur mesure
Certains problèmes ne se résolvent pas avec un site web. Quand le besoin est un outil, une application, une intégration ou un processus qui ne devrait plus se faire à la main, c'est cela que nous construisons.
Une équipe petite, expérimentée, et honnête sur le périmètre. Si un produit existant résout déjà votre problème, nous vous le dirons plutôt que de vous facturer pour le reconstruire.
Registre
Le type de projets que nous menons
Une bonne façon de décrire un logiciel sur mesure est par le problème qu'il élimine. Voici les cas de figure qui reviennent le plus souvent, et ce que nous finissons généralement par construire.
| Le problème | Ce que nous construisons |
|---|---|
| La même tâche manuelle, chaque jour, effectuée par une personne trop qualifiée pour ça | Un outil interne où les étapes sont codées une bonne fois pour toutes : un formulaire, une file d'attente, un historique clair, et des permissions qui correspondent à la façon réelle de travailler de l'équipe. |
| Deux systèmes qui refusent de communiquer entre eux | Une intégration qui prend en charge la correspondance entre eux, relance en toute sécurité quand un côté est indisponible, et vous prévient quand quelque chose nécessite une intervention humaine. |
| L'activité qui repose sur un tableur que personne n'ose toucher | Une petite application web avec un vrai modèle de données derrière, pour que deux personnes puissent travailler en même temps et que les chiffres du trimestre dernier ne puissent pas être écrasés par accident. |
| Un rapport que quelqu'un assemble à la main chaque semaine | Une tâche planifiée qui rassemble les données, les vérifie, et livre le rapport aux personnes concernées, avec un historique de chaque exécution. |
| Un travail qui se fait loin d'un bureau : sur un téléphone, dans une camionnette, dans un atelier | Une application mobile sur le même socle que le reste du système, partageant son modèle de données, son standard de relecture et ses vérifications automatisées, pour que le téléphone et l'ordinateur ne soient jamais en désaccord sur les faits. |
| Un parcours client greffé sur un site vitrine jusqu'à ce qu'il cède | Une véritable application à sa propre adresse, partageant le système de design du site pour que tout continue à ressembler à une seule et même entreprise. |
| Quelque chose que personne ne peut chiffrer parce que personne ne l'a cadré | Une courte étape de cadrage : la plus petite version fonctionnelle définie par écrit, avec les parties que nous ne construirions pas listées tout aussi clairement. |
Discernement
Comment nous décidons quoi construire
- La plus petite chose qui fonctionne, d'abord. Un outil restreint en production vous apprend plus en deux semaines qu'une spécification complète en un trimestre, et il peut être étendu une fois que vous savez quelles parties comptent vraiment.
- Une technologie volontairement sobre. Nous choisissons l'option éprouvée plutôt que l'option intéressante. Un logiciel sur mesure se juge le jour où quelqu'un doit le modifier, pas le jour de son lancement.
- Bien poser le modèle de données, tôt. Une interface se redessine à peu de frais, une donnée se restructure à grands frais ; la forme des données est donc arrêtée avant celle des écrans.
- Acheter avant de construire. Si un produit sous licence couvre déjà votre cas, la recommandation honnête est de l'utiliser. Nous préférons construire la petite pièce qui le relie plutôt que vous facturer pour le réinventer.
- Concevoir pour le second développeur. Du code lisible, une installation documentée, des tests qui expliquent l'intention. La mesure du travail, c'est si quelqu'un d'autre peut le modifier en toute sécurité.
Stack
Les technologies que nous utilisons réellement
Les nommer fait partie de l'honnêteté sur le périmètre. Un acheteur technique doit pouvoir juger en un seul écran si nous sommes le bon studio, et un acheteur non technique doit pouvoir transmettre cette section à son propre développeur et obtenir une réponse claire.
TypeScript, de bout en bout
Astro, HTML et CSS natifs, React quand une application en a besoin, ainsi que les applications mobiles
Node et Cloudflare Workers
Bases de données compatibles Postgres, migrations SQL versionnées
Cloudflare Pages, Workers, stockage d'objets, déclencheurs planifiés
Playwright, Vitest, typage statique, audits d'accessibilité automatisés
- Un seul langage pour tout le système. TypeScript pour l'interface, l'API, les tâches planifiées et les tests, avec les types vérifiés à chaque modification. Un seul langage, c'est une seule chaîne d'outils et un seul standard de relecture, sans couche de traduction entre le navigateur et le service qui se trouve derrière.
- Le rendu choisi selon le besoin. Le contenu se compile en HTML statique. Une interface qui a réellement besoin d'état côté client reçoit un framework de composants, limité à la partie de l'écran qui en a besoin, plutôt qu'un framework enveloppant un contenu qui ne change jamais.
- Les applications mobiles, avec la même exigence. Là où le travail se fait davantage dans la main de quelqu'un que dans un onglet de navigateur, nous construisons l'application selon le même standard que tout le reste : la même chaîne d'outils orientée TypeScript, le même standard de relecture, les mêmes vérifications automatisées, et le même modèle de données que le service qui se trouve derrière, plutôt qu'une seconde version de la vérité. Le choix de la technologie pour une application donnée est une décision que nous prenons avec vous pendant que le périmètre s'écrit, pas une préférence maison appliquée à chaque projet.
- Une base de données relationnelle, pas un fourre-tout documentaire. Une base compatible Postgres avec une couche de requêtes typée, et des changements de schéma relus, appliqués dans l'ordre et réversibles. Personne ne modifie un schéma de production à la main.
- Serverless par défaut, parce qu'il n'y a aucun serveur à oublier. Le code s'exécute sur la plateforme en périphérie de Cloudflare, avec du stockage d'objets pour les fichiers et des tâches planifiées pour tout ce qui doit se déclencher à intervalle fixe. Aucune machine à vous à corriger à minuit, aucune capacité à deviner.
- Des intégrations via des interfaces documentées. Les autres systèmes sont atteints par leurs API et webhooks, avec relances, idempotence et un historique de chaque appel. Quand un fournisseur n'offre aucune API, un flux de fichier ou de données planifié est la solution de repli assumée, jamais l'extraction de contenu depuis une page qui cassera au prochain trimestre.
- Les environnements et les secrets comme configuration, jamais comme tradition orale. L'infrastructure est déclarée dans le dépôt, les identifiants vivent dans un coffre-fort de secrets et atteignent le service en fonctionnement sous forme de variables d'environnement, et une nouvelle machine fait tourner le projet dès l'après-midi même.
- Votre stack, quand vous en avez déjà une. Si votre équipe maintient déjà quelque chose de raisonnable, la bonne réponse est généralement de travailler dedans plutôt que d'introduire une seconde façon de tout faire. Et si ce que vous avez est réellement le problème, vous l'entendrez aussi.
Standards
Le même socle d'ingénierie que pour les sites web
Le socle ne change pas entre les deux lignes de service, car un outil interne est utilisé pendant des années par des personnes qui n'ont pas le choix d'en changer. Du code standard dans un dépôt avec son historique complet, des vérifications automatisées qui bloquent un déploiement en échec, des mises en production en une seule commande réversibles en une étape, des interfaces accessibles (les équipes méritent le même niveau que les clients), des secrets tenus hors du code, et aucune plateforme propriétaire en dessous de tout cela. Tout cela est détaillé du côté des sites web d'entreprise plutôt que répété ici.
Deux choses pèsent plus lourd dans un logiciel que sur un site, et elles méritent d'être nommées séparément.
Les données survivent au code
Les interfaces se remplacent ; les données restent. Les changements de schéma sont donc des migrations dans le dépôt, appliquées dans l'ordre et réversibles, les sauvegardes relèvent de la plateforme plutôt que d'un script écrit une fois par quelqu'un, et vos données peuvent être exportées dans un format que vous pourriez charger ailleurs, entièrement.
Un système en fonctionnement doit être observable
Tout ce qui se produit sans que personne ne regarde laisse une trace : ce qui s'est exécuté, quand, ce que ça a touché et sur quoi ça a échoué. Une tâche planifiée qui s'arrête de fonctionner discrètement nous le signale, au lieu d'être découverte un mois plus tard par la personne qui se demandait où était passé son rapport.
Périmètre
Où nous nous arrêtons
Être clair sur les limites fait partie de la confiance que nous inspirons. Nous sommes une petite équipe expérimentée : nous prenons les projets que nous pouvons bien mener, et nous disons non à ceux que nous ne pouvons pas.
Nous ne revendons pas de plateformes sous licence, nous ne staffons pas un projet que nous ne construisons pas nous-mêmes, et nous ne chiffrerons pas un problème qui n'a pas été cadré. Quand une partie du travail relève d'un spécialiste, nous vous le dirons clairement plutôt que de le découvrir à vos dépens.
Les limites techniques sont tout aussi précises :
- Utiliser un modèle oui, la data science non. Nous appelons un modèle hébergé ou un service existant depuis votre application, et construisons l'interface et la mécanique autour. Entraîner des modèles, faire de l'analyse statistique ou construire des pipelines de données à l'échelle d'un entrepôt de données, ce n'est pas notre métier.
- Des plateformes managées oui, vos propres serveurs non. Nous déployons sur des plateformes en périphérie et serverless managées. Si le projet doit tourner dans votre datacenter, sur des machines que vous administrez, ou sur un système d'exploitation que quelqu'un doit garder à jour, nous ne sommes pas le bon studio, et vous l'entendrez dès le premier appel.
- Les référentiels de certification nécessitent un spécialiste à nos côtés. Nous appliquons une véritable ingénierie de sécurité par principe, mais un audit formel selon un référentiel nommé est une spécialité que nous ne vendons pas. Si votre projet en a besoin, nous le disons avant que vous ne signiez quoi que ce soit, pas après.
- Micrologiciels, et revente. Les micrologiciels embarqués ne relèvent pas de notre discipline, pas plus que tout ce dont la valeur serait une licence revendue plutôt qu'un travail réalisé.
Exploitation
Qui garde le système opérationnel par la suite
Un logiciel sur mesure n'est pas terminé au lancement. Il est utilisé, puis il doit évoluer. Qui l'exploite et qui le fait évoluer doit figurer dans le périmètre dès le départ, pas dans un e-mail gênant six mois plus tard.
Nous l'hébergeons et le faisons tourner
C'est l'option par défaut : nous hébergeons et exploitons le système pour un forfait mensuel, et les évolutions après le lancement suivent la même boucle que la construction, à savoir une branche, une prévisualisation, l'ensemble des vérifications, et un déploiement réversible en une étape. Les personnes qui l'ont écrit sont celles qui le surveillent en production, ce qui fait généralement la différence entre un correctif discret et un long échange sur la responsabilité de chacun.
Être une petite équipe expérimentée a un coût, et nous préférons le dire clairement : nous n'assurons pas d'astreinte 24 heures sur 24 et ne vendons pas de délai de réponse garanti en minutes. Si votre projet en a réellement besoin, dites-le nous tôt, et nous vous dirons honnêtement si nous pouvons y répondre.
Ou vos propres équipes prennent le relais
Là où votre contrat le prévoit, le logiciel peut basculer vers votre propre hébergement et vos propres développeurs : du code standard, les tests, l'installation documentée et un déploiement en une seule commande. C'est précisément à cela que sert la conception pour le second développeur, évoquée plus haut. C'est une option que nous mettons par écrit quand vous le souhaitez, pas l'arrangement par défaut.
La plateforme aide aussi sur ce point. Un site statique et un service serverless n'ont ni serveur à corriger ni système d'exploitation à maintenir à jour ; il ne reste donc que les mises à jour des dépendances et de la plateforme : un changement planifié et relu, jamais une urgence.
Vous n'avez pas besoin d'une spécification pour commencer. Écrivez-nous via le formulaire de contact ou à [email protected], et décrivez le projet avec vos propres mots.