Des apps livrées.La qualité se voit.

Si c'est une app web ou mobile avec des comptes, des données et de vrais utilisateurs, oui — c'est ce qu'on construit, des produits qui doivent tenir, pas des démos. Un site vitrine ou un script jetable, plutôt non, et on te le dira franchement. Pas encore sûr ? On commence par un cadrage court et payant qui transforme l'idée en périmètre, architecture et estimation — et tu le gardes, qu'on construise la suite ensemble ou non.

Pas de tarif sur cette page, volontairement — un chiffre sans ton périmètre, ce serait une devinette. Ce qui le fait varier est clair : ce que fait l'app, les services auxquels elle se branche, la complexité des données et la tension du calendrier. On cadre d'abord ensemble, puis tu reçois un prix ferme par écrit avant que le build commence. S'il ne te convient pas, tu gardes le cadrage et tu pars.

Avec ton app. Le code, le dépôt, l'infrastructure et les comptes sont à toi, transférés à ton nom à la livraison. Rien ne dépend d'Aeria pour tourner — pas de couche propriétaire, pas de licence à renouveler — et un autre développeur peut la reprendre dès le lendemain.

Un mot de passe volé ne suffit pas à lui seul. L'identité repose sur une authentification à deux facteurs sur chaque compte, posée dès le départ plutôt qu'ajoutée à la fin — le premier verrou, le plus intérieur, parce que si l'identité est fausse, rien de ce qui l'entoure ne tient. C'est le standard qu'on livre, pas une affirmation sur un build précis.

C'est la base de données elle-même qui refuse. Avec la row-level security, chaque compte ne lit et n'écrit que ses propres lignes — appliqué là où vivent les données, pas seulement dans un code applicatif qu'on peut oublier d'appeler. C'est le deuxième verrou : il limite les dégâts même quand quelque chose au-dessus se trompe.

Rien n'arrive en production sans une pipeline verte : types, lint, tests et build doivent tous passer d'abord, et si l'un est rouge, la modif ne part pas. Ça ne rend pas les bugs impossibles — ça arrête les évidents à la porte, et quand quelque chose passe quand même, le correctif arrive avec un test pour qu'il ne revienne pas en silence. C'est le troisième verrou.

On durcit le cadre autour de l'app : des en-têtes HTTP de sécurité posés volontairement — politique de contenu, sécurité du transport, protection contre l'intégration en cadre et le sniffing de type — avec pour barre un A sur un scanner public. C'est le dernier verrou, le cadre extérieur, et c'est celui que tu peux vérifier toi-même en une minute : ne nous crois pas sur parole, vérifie.

Pas de promesse avant d'avoir lu ton périmètre — un délai inventé d'avance, c'est du marketing. On le fixe au cadrage, d'après ce qu'il y a à construire, les intégrations en jeu et ta réactivité à nos questions. Tu le reçois par écrit avec le prix, et chaque étape livre quelque chose que tu peux ouvrir et essayer.

Bonne question, et on ne va pas l'enjoliver : on est jeunes, et il n'y a pas de mur de logos connus. À la place, tu as quelqu'un de responsable, nommément ; des mains seniors sur le code plutôt qu'une chaîne de sous-traitance ; les quatre verrous ci-dessus comme standard vérifiable ; et tout dans tes propres comptes pour pouvoir partir. Regarde ce qu'on a livré et juge là-dessus.

Non. À la livraison, tu reçois une passation : code, documentation, accès, et comment le faire tourner. Ensuite, tu choisis — nous garder en suivi optionnel pour les correctifs et les évolutions, le reprendre en interne, ou le confier à quelqu'un d'autre. Le suivi est un choix, pas un enfermement, et tu peux l'arrêter.

Ça dépend du formulaire. Celui de la page Reprise prépare un e-mail dans ton propre client : le remplir n'envoie rien. Celui de « Décrire mon projet » envoie tes réponses à notre serveur, qui rédige le brief et nous l'envoie par e-mail — ou te le rend à envoyer toi-même. Rien d'autre : aucun analytics, aucun traçage. Si tu préfères signer un accord de confidentialité avant de donner des détails, envoie le tien ou demande le nôtre.

Oui — c'est un travail à part, avec sa propre page. On lit l'existant, puis on te dit franchement ce qu'on garde, corrige ou reconstruit, et pourquoi, avant de l'amener au même standard que le reste. Reprendre une app vibe-codée