Nous construisons des
produits logiciels complets, et la couche qui se trouve dessous.
Nous menons des idées de produit difficiles du périmètre jusqu'au logiciel livré : interface, backend, IA, infrastructure, sécurité et passation. Quand la difficulté se situe sous la couche applicative, nous travaillons là aussi.
Voir les exemples de livrables
Deux branches, et la boucle qui les relie.
Le travail produit pour nos clients est l'offre. Les logiciels que nous possédons sont ce qui garde l'ingénierie assez profonde pour mériter d'être achetée. C'est une seule pratique, pas deux, et la même exigence s'applique aux deux.
Ce que nous construisons pour nos clients
De l'ingénierie produit complète pour les entreprises qui ont besoin d'une vraie profondeur plutôt que d'un modèle prêt à l'emploi : périmètre, interface, backend, IA, infrastructure et sécurité, pris en charge de bout en bout. C'est le travail que vous pouvez acheter aujourd'hui, avec la même ingénierie et les mêmes exigences que tout ce qui suit.
Ce que nous prenons en chargeCe que nous possédons
Des logiciels système conçus à partir des principes fondamentaux plutôt que posés sur le produit de quelqu'un d'autre : un système d'exploitation maison basé sur Linux, des plateformes pour développeurs et des outils assistés par IA. De la R&D que nous possédons, pas quelque chose que nous vendons aujourd'hui, et la raison pour laquelle le jugement en infrastructure et en sécurité sur une réalisation client vaut son prix. Chaque élément affiche son stade réel.
Voir l'établiCe que nous partageons
Nous écrivons sur les rouages : comment les systèmes fonctionnent vraiment, ce que nous apprenons en construisant un système d'exploitation, les décisions derrière les outils. Pas du marketing déguisé en articles de blog. De la vraie écriture technique pour celles et ceux qui construisent.
Lire les derniers articles
Trois réalisations internes.
Trois types de systèmes différents : une surface produit, un système de données et une couche de système d'exploitation. Ensemble, ils montrent l'étendue, pas une spécialité.
- / 01
Garder un modèle de création et son rendu en accord
Une plateforme de contenu multi-locataire. Ce que l'utilisateur édite et ce qu'un navigateur reçoit sont deux artefacts différents, et les maintenir en accord est tout le problème, qui revient dans les permissions, les domaines et la facturation.
- / 02
Transformer une question en requête vérifiable
Un système d'analyse en langage naturel. Le SQL généré est du code non fiable dirigé vers une vraie base de données : il est donc validé avant d'être exécuté et affiché à côté de son résultat plutôt que caché.
- / 03
Détenir root sans le transmettre
Un gestionnaire d'affichage, le niveau le plus bas qu'atteigne une réalisation. Il authentifie, détient root et démarre une session qui ne doit jamais hériter de cette autorité, sur une machine où une défaillance ne laisse aucun écran pour déboguer.
Des produits complets, avec de la profondeur dessous.
L'ingénierie produit est l'offre. Les trois catégories en dessous sont la profondeur dont un produit difficile a besoin, et la raison pour laquelle le travail ne s'arrête pas à la couche applicative.
Ingénierie produit
Une réalisation complète : périmètre, interface, backend, intégrations, déploiement et passation. L'ensemble, ou la partie qui bloque le reste.
IA et automatisation
Des systèmes d'agents et de l'automatisation qui tiennent à l'usage réel : limites des outils, contexte maîtrisé, évaluation avant la mise en production d'un changement.
Plateforme et infrastructure
L'environnement d'exécution d'un produit : provisionnement en code, CI, déploiement et retour arrière, et des défaillances qui se manifestent au lieu de se cacher.
Sécurité et profondeur système
Frontières d'accès, moindre privilège, durcissement, et le débogage de bas niveau qui commence là où s'arrêtent les journaux applicatifs.
Conçu pour la charge, la défaillance et le retour arrière.
Le vocabulaire dans lequel le travail est construit, et les trois modes de défaillance autour desquels il est conçu dès le départ.
Pensée système
Processus, services, limites de ressources et modes de défaillance sont le vocabulaire de travail, pas des détails après coup. Un système se pense à partir des pièces mobiles qu'il comporte réellement.
Sécurité par défaut
On suppose une entrée hostile, le système échoue en mode fermé et le moindre privilège s'applique dès le premier commit. La sécurité est la position de départ, pas une étape de durcissement ajoutée avant le lancement.
Défaillance et reprise
La conception tient compte de ce qui se passe quand une pièce casse et de la façon dont elle revient. La reprise est planifiée, pas improvisée une fois que tout est déjà à l'arrêt.
- interfacece que les gens touchent
- servicesles pièces mobiles
- donnéesétat et flux
- exécutionprocessus et limites
- infrastructurece sur quoi tout tourne
Les trois autour desquels tout est conçu
Conçu pour tenir sous la charge
Les budgets de latence et de coût sont fixés avant la réalisation : la charge a un plafond connu dès la conception, au lieu de devenir une surprise en production.
Conçu pour contenir une défaillance
Chaque pièce reçoit un rayon d'impact borné : la panne d'un élément ne peut pas entraîner le reste du système avec elle.
Conçu pour pouvoir être annulé
Les déploiements sont conçus pour être réversibles et les environnements pour se reconstruire depuis les sources : la reprise est un retour arrière, pas un sauvetage.
Du premier contact au lancement, un seul chemin.
L'arc complet de votre point de vue : ce qui se passe avant tout engagement, puis la façon dont la livraison se déroule une fois l'engagement pris.
- 01
Un appel ou un brief écrit
Vous commencez par un appel si le problème prend encore forme, ou par un brief si le périmètre et les contraintes sont déjà arrêtés. Dans les deux cas, vous joignez la même personne.
- 02
Un document de cadrage
La conversation devient un document court : le problème tel qu'il est compris, ce qui sera construit, ce qui ne le sera pas, et ce qui compte comme terminé.
- 03validé
Validé avant tout démarrage
Vous lisez le périmètre et vous l'approuvez. Rien n'est facturé tant que ce document n'est pas arrêté : l'engagement vous appartient.
- 04
Construit par incréments vérifiables
La livraison avance par étapes, selon ce périmètre. Chaque incrément peut être inspecté : l'avancement est visible au lieu d'être promis.
- 05
Lancé avec son raisonnement
Le système passe en production avec son runbook et les décisions qui le sous-tendent. Vous obtenez quelque chose que vous pouvez exploiter et confier au prochain ingénieur sans fouilles archéologiques.
Des lignes que nous ne franchirons pas.
Quatre refus, énoncés d'emblée pour que vous n'ayez pas à les découvrir plus tard.
Nous ne livrerons pas une démo incapable de survivre en production
Si elle ne tient que sur le chemin idéal, elle n'est pas terminée. Le critère est un système qui continue de fonctionner sous une charge réelle et des entrées réelles.
Nous ne cacherons pas le raisonnement derrière une décision
Chaque choix non évident est livré avec ses raisons. Vous n'aurez jamais à faire de la rétro-ingénierie sur un choix que quelqu'un a fait sans l'écrire.
Nous ne confierons pas votre système à un sous-traitant anonyme
Le travail n'est pas confié dans votre dos à une agence ou à un freelance de plateforme. Si une partie exige un spécialiste, vous l'apprenez pendant le cadrage et vous décidez.
Nous n'ajouterons pas de pièce mobile incapable de se justifier
Chaque composant mérite sa place ou disparaît. Rien ne reste dans le système parce que le retirer serait gênant.
Vous parlez aux personnes qui comprennent réellement ce que vous construisez.
Une communication directe avec les ingénieurs qui font le travail, sans intermédiaire de type chargé de compte entre vous et eux. Un seul responsable reste au plus près du périmètre, de l'architecture, de la réalisation et de la passation.
Dites-nous ce que vous construisez.
Un produit entier, ou la partie qui bloque le reste. Un brief écrit ou un appel conviennent aussi bien : commencez par la contrainte qui est vraiment difficile.