Réponse sous trois jours ouvrés

Votre pic de trafic n'est pas un incident.C'est mardi.

Altessa Solutions construit des plateformes à forte charge, des applications clientes et de l'IA qui tiennent en production. Vous parlez aux ingénieurs qui feront le travail, dès le premier appel.

Obtenir un avisNotre méthode
chaque changement est relu par un second ingénieuravant d'arriver en production
Quoi
Plateformes à forte charge. Applications clientes. IA en production.
Comment
Projet à périmètre fixe. Équipe dédiée. Renfort d'équipe.
Départ
Semaine de découverte, démarrage sous dix jours ouvrés.
Secteurs
  • Fintech et paiements
  • Mobilité
  • Streaming média
  • Télécoms
  • Healthtech
  • Marketplaces

Pourquoi nous commençons par lire

La charge ne casse pas les systèmes. Les décisions prises deux ans plus tôt, si.

Nous commençons donc par votre code, pas par un devis. La semaine de découverte montre lesquelles de ces décisions peuvent encore être défaites à peu de frais, et lesquelles non.

§ 01 — Ce que nous faisons

Trois pratiques qui doivent fonctionner ensemble.

La plupart des missions commencent dans une pratique et finissent par en mobiliser deux. L'application a besoin d'un backend qui tient ; le backend a besoin d'un modèle qui reste dans son budget.

01

Plateformes à forte charge

GoJavaC#.NETKotlingRPCProtobuf 3KafkaNATSNATS JetStreamRabbitMQPostgreSQLMongoDBClickHouseRedisElasticsearchk8s

Des systèmes qui se mesurent en requêtes par seconde. Cœurs événementiels, stockage shardé, écritures idempotentes, et une marge que nous prouvons par des tests de charge avant que vos utilisateurs ne la testent à notre place. En surcharge, ils délestent volontairement au lieu de tomber.

Typique : 5–8 ingénieurs, 4–6 mois, SLO convenu par écrit

  • 01Revue d'architecture et plans de migration
  • 02Cœurs de paiement, de réservation et de streaming
  • 03Migration sans interruption : double écriture, backfill, bascule
  • 04Un banc de charge qui reproduit votre pic, plus des exercices de panne
  • 05Conception des SLO, observabilité, runbooks d'astreinte

02

Applications clientes

SwiftSwiftUIKotlinComposeKMPWinUIC#.NETQtC / C++Java

Natif iOS, Android, macOS et Windows, avec un cœur partagé là où il se rentabilise. Données offline-first, télémétrie dès le premier build, releases à cadence fixe.

Typique : 3–5 ingénieurs, 3–5 mois jusqu'au store, une release toutes les deux semaines

  • 01Windows 10/11, macOS, Linux, Android, iOS/iPadOS, watchOS
  • 02Publication sur les stores, CI, déploiements progressifs
  • 03Télémétrie des crashs, de la latence et des tunnels

03

IA en production

PythonPyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflow

Retrieval, agents et serving de modèles, avec les parties ingrates terminées : jeux d'évaluation, garde-fous, plafonds de coût, budgets de latence. Une démo prend un week-end ; un SLA prend plus longtemps. Nous mesurons la qualité sur vos données avant le lancement, et continuons après.

Typique : 2–4 ingénieurs, 8–12 semaines jusqu'à la première tranche en production

  • 01Retrieval et recherche sur vos propres données
  • 02Workflows d'agents avec points de contrôle humains
  • 03Suites d'évaluation qui conditionnent chaque changement de modèle
  • 04Un chemin de repli quand le fournisseur est en panne
  • 05Inférence auto-hébergée et maîtrise du coût GPU

§ 02 — Exemples

Les problèmes pour lesquels on nous appelle.

Tirés de schémas récurrents dans nos projets, pas d'un seul client. Ce avec quoi les gens arrivent, ce qu'il y a généralement derrière, et ce que nous changeons.

“Chaque promo finit en incident, et il n'y a pas le temps de réécrire.”

Nous ne réécrivons pas tout. Le chemin chaud passe dans son propre cœur, les écritures deviennent rejouables sans risque, et la migration tourne en production pendant que l'ancien code continue de servir jusqu'au dernier jour.

Plateformes · en général 5–8 ingénieurs, 4–6 mois

“Une release prend un trimestre et personne ne sait dire pourquoi.”

C'est rarement le code. C'est la régression manuelle et une branche que personne n'ose merger. Nous séparons le train de release du travail sur les fonctionnalités, automatisons le pack de régression et mettons les parties risquées derrière des flags.

Applications clientes · en général 3–5 ingénieurs, 3–5 mois

“La démo IA a impressionné tout le monde et n'est jamais sortie.”

Parce qu'une démo ne compte pas l'argent et ne répond pas de ses erreurs. Nous ajoutons un jeu d'évaluation, un plafond de coût, un chemin de repli et un humain dans la boucle là où une erreur coûte cher.

IA en production · en général 2–4 ingénieurs, 8–12 semaines

Ce que vous voyezCe qu'il y a dessousCe que nous faisons

Chaque promo finit en incident

Écritures synchrones vers une seule base, paiements en double, rollback manuel

Cœur événementiel, écritures idempotentes, migration sans fenêtre de maintenance

L'app sort une fois par trimestre

Régression manuelle, deux bases de code, une branche que personne n'ose merger

Cœur Kotlin partagé, régression automatisée, un train de release toutes les deux semaines

Le support n'arrive pas à vider la file

Le savoir dans les têtes, des réponses non reproductibles, le pilote IA jamais sorti

Retrieval sur vos propres données, évaluations à chaque release, inférence auto-hébergée

Aussi sur la liste

  1. 01

    La recherche ralentit à mesure que le catalogue grossit

    Le ranking hors de la base principale, un budget sur chaque chemin de requête

    3–4 mois
  2. 02

    La télémétrie a dépassé sa base de données

    Ingestion dans un flux, historique dans une base colonne, rapports sans timeouts

    3 mois
  3. 03

    Deux bases de code au lieu d'une équipe

    Un cœur KMP partagé, une UI native là où la plateforme l'attend

    3–5 mois
  4. 04

    Plus personne de ceux qui ont écrit le système

    Un audit, des décisions écrites et une équipe capable de le porter

    dès 1 sem.

§ 03 — Comment ça se passe

Cinq étapes, à commencer par une semaine.

La semaine de découverte est une mission payante à part entière, €12k forfaitaires. Elle produit une architecture, une liste de risques classés et un prix. Si l'un des trois vous déçoit, ça s'arrête là et vous gardez les documents.

  1. 01semaine 1

    Semaine de découverte

    Votre code, vos courbes de charge, votre échéance. Nous lisons avant de parler.

  2. 02fin de semaine 1

    Architecture et estimation

    Un seul document : architecture cible, chemin de migration, forme de l'équipe, fourchette de prix.

  3. 03toutes les 2 semaines

    Itérations de deux semaines

    Des incréments sur staging, démontrés en direct, burn chart joint.

  4. 04avant le lancement

    Tests de charge et lancement

    Tests d'endurance, exercices de panne, un rollback répété. Le jour du lancement doit être sans histoire.

  5. 05en continu

    Exploiter ou transmettre

    Nous restons d'astreinte, ou nous formons votre équipe et lui laissons les runbooks.

Ce que vous avez en main après la première semaine

  • Architecture cible, et ce que nous garderions
  • Registre des risques, classés par rayon d'impact
  • Modèle de capacité pour les 18 prochains mois
  • Forme de l'équipe, calendrier et fourchette de prix
  • Une décision go / no-go à présenter à votre conseil
  • Le tout dans votre dépôt, à vous pour de bon

§ 04 — L'équipe

Ceux qui le conçoivent sont ceux qui le font tourner.

Quarante ingénieurs salariés. Vous rencontrez ceux qui écriront le code, ils restent sur le projet jusqu'à la fin, et personne n'est déplacé en cours de route pour boucher un trou ailleurs.

Backend et plateforme
18
Mobile et desktop
9
IA et données
7
SRE, QA, design
6

Principe 01

Ingénieurs seniors

Neuf ans d'expérience en médiane. Les juniors apprennent sur nos outils internes, pas sur votre production.

Principe 02

D'astreinte avec vous

Les ingénieurs qui ont construit un système en portent l'astreinte.

Principe 03

Des décisions écrites

Chaque décision d'architecture a une trace écrite dans votre dépôt, pas un message dans un fil de chat.

Principe 04

Pas de lock-in

Votre cloud, vos dépôts, votre CI. Nous quitter doit demander une invitation d'agenda, pas une migration.

§ 05 — Modèles de collaboration

Une équipe, un projet, ou un seul spécialiste.

Choisissez la forme qui convient au travail, pas l'inverse. Changer de modèle en cours de mission est normal et ne remet rien à zéro.

ModèleIdéal pourÉquipeEngagementCadenceDès
Projet à périmètre fixeUn lancement défini avec une date ferme4–8 personnes3+ moisJalons, prix fixe par phase€100k / phase
Équipe dédiéePorter une ligne de produit de bout en bout5–12 personnes6+ moisMensuel, préavis de 30 jours€9.5k / ingénieur / mois
Renfort d'équipeDes postes précis dans vos propres squads1–5 personnes3+ moisÀ l'heure, relevés hebdomadaires€58 / heure

Inclus dans chaque modèle

  • Tarifs par ingénieur, sur 160 heures facturables par mois
  • Delivery lead et QA, sans facturation séparée
  • Revue de sécurité avant chaque release
  • NDA et accord de traitement des données RGPD
  • Cession complète de la PI au paiement
  • Point écrit chaque semaine, comité de pilotage chaque mois

§ 06 — La stack dont nous répondons

Des outils classiques, bien employés.

L'outil suit le problème : ce que la charge, l'échéance et vos systèmes existants exigent réellement. Tout choix inhabituel vient avec une raison écrite et un plan de sortie.

Backend

GoJavaKotlinC#.NETC / C++PythonNode.jsRustSpring BootASP.NET CoregRPCProtobuf 3GraphQL

Web et frontend

TypeScriptVue.jsNuxtNext.jsReactNode.jsViteWebSocketSSR

Données et messagerie

PostgreSQLMongoDBClickHouseElasticsearchRedisKafkaNATSNATS JetStreamRabbitMQDebeziumAirflow

Infrastructure

KubernetesHelmDockerTerraformArgoCDGitHub ActionsAWSGCPBare metalPrometheusGrafanaOpenTelemetry

Mobile et desktop

iOSiPadOSwatchOSmacOSWindows 10/11AndroidLinuxSwiftSwiftUIKotlinComposeKMPC#.NETWinUIQtFlutter

Charge et qualité

k6GatlingJMeterTestcontainersPlaywrightpprofExercices de panne

IA et ML

PyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflowAPIs Claude / OpenAI

§ 07 — En public

Ce que nous publions.

Des bibliothèques extraites de travaux clients et des notes écrites en résolvant quelque chose. Tout ce que nous publions vit au même endroit :

github.com/altessa-s

§ 08 — Comment nous décidons

Les décisions d'architecture sont écrites.

Pas un document que personne ne lit : une courte fiche par décision, dans votre dépôt, relue comme du code. Un an plus tard, la question "pourquoi c'est construit comme ça" a une réponse.

  1. 01

    La bifurcation est écrite avant d'être prise

    Les options, ce que chacune coûte, et ce que nous abandonnerions. Deux paragraphes, pas un deck.

  2. 02

    Elle est relue comme du code

    La fiche passe par une pull request. Votre architecte peut la contester avant que quoi que ce soit ne soit construit, pas après.

  3. 03

    La raison est consignée, pas seulement le choix

    Contraintes, hypothèses de charge et date. La plupart des mauvaises réécritures commencent parce que personne ne se souvient de la contrainte.

  4. 04

    Elle dit quand la revoir

    Chaque fiche porte la condition qui l'invaliderait — un seuil de charge, un plafond de coût, un changement de fournisseur.

§ 09 — Là où nous disons non

Le travail que nous refusons.

  • Nous ne chiffrons pas sans accès au code

    Une estimation sur un deck de slides est une supposition, et l'un de nous finit toujours par la payer.

  • Nous ne vendons pas de juniors pour des seniors

    Si nous ne pouvons pas composer un projet d'ingénieurs seniors, nous le disons et passons notre tour.

  • Nous ne réécrivons pas pour réécrire

    Deux fois, nous avons recommandé de laisser un système tranquille et de partir. C'était moins cher pour tout le monde.

  • Nous ne faisons ni sites web ni landing pages

    Pas de sites marketing, pas d'apps jetables construites pour une date puis abandonnées. Si ce n'est pas un système que quelqu'un devra faire tourner, nous ne sommes pas la bonne équipe.

  • Nous ne vous prenons pas en otage

    Votre cloud, vos dépôts, 30 jours de préavis et les runbooks en partant.

§ 10 — Les questions qui viennent tôt

Posez d'abord celles qui fâchent.

Si votre question n'est pas ici, mettez-la dans le formulaire ci-dessous. Un ingénieur répond, par écrit.

La semaine de découverte commence sous dix jours ouvrés après la signature du cahier des charges, et l'équipe est constituée à la fin de cette semaine, parmi nos propres salariés. Si nous ne pouvons pas la composer d'ingénieurs seniors, nous le disons et déclinons le projet.

Dites-nous ce qui casse sous la charge.Nous vous dirons ce que nous ferions.

Obtenir un avis

§ 11 — Contact

Écrivez-nous.

Décrivez le système et ce qui ne va pas. Un ingénieur le lit et répond sous trois jours ouvrés.

La suite

Jours 1–3
Un ingénieur lit votre message et répond par écrit avec une première lecture : ce que nous pensons qu'il se passe et ce que nous regarderions en premier.
Si utile
Un court appel avec ce même ingénieur, au créneau de votre choix. Seulement si la réponse écrite laisse quelque chose en suspens.
Si ça colle
Nous cadrons la semaine de découverte : une semaine à lire votre code, €12k forfaitaires, architecture et prix à la sortie.
Modèle de collaboration

NDA sur demande. Vos données restent dans l'UE. Nous répondons nous-mêmes, sans séquences automatisées.

Ce site est protégé par reCAPTCHA ; les Règles de confidentialité et Conditions d'utilisation de Google s'appliquent.

Vous préférez répondre à quelques questions plutôt qu'écrire un message ?Remplir le brief