Waypoint
Mission freelance pour Better Call Us - infrastructure complète du MVP
2026 | Livré, produit aujourd'hui en ligne
Le produit appartient à Better Call Us, qui m'a autorisé à en parler. Ce qui suit décrit mon travail d'infrastructure, pas le leur.
Le produit
Waypoint fait développer, déployer et vérifier des demandes Salesforce par des agents IA, sur abonnement mensuel.
On décrit le besoin
Pas de spécification à rédiger. Atlas, l'agent architecte, lit l'org Salesforce du client et revient avec des demandes découpées et estimées.
Le client valide
Rien ne part en développement sans accord. Chaque demande affiche ce qu'elle consomme avant d'être lancée.
C'est développé et vérifié
Objets, champs, flows, Apex : Milo écrit, déploie sur une org de développement, puis vérifie contre l'org réelle. Un échec remonte avec sa raison.
Le client choisit où ça atterrit
Avec plusieurs orgs, une chaîne de promotion développement, recette, production laisse décider quand une release monte d'un cran.
Le contexte
Better Call Us avait un produit à construire et personne pour tenir la partie infrastructure.
La demande
Construire l'intégralité de l'infrastructure du MVP : provisionnement, configuration, pipelines de déploiement, supervision, sauvegardes, et la documentation qui permet à l'équipe de reprendre la main.
J'ai commencé par un document d'architecture technique, validé par le client avant la première ligne de configuration.
La contrainte
Les agents de Waypoint tournent dans des traitements Python longs, de l'ordre de plusieurs minutes, avec un accès au système de fichiers. Le tout-serverless était donc exclu.
Il fallait un frontend déployé en continu et un environnement persistant à côté, sans faire exploser ni la facture ni la charge d'exploitation d'une petite équipe. D'où une architecture hybride plutôt qu'un seul fournisseur.
L'architecture
Chaque brique a été choisie contre une alternative, et le choix est écrit dans le document d'architecture.
| Couche | Composant | Rôle |
|---|---|---|
| Frontend | Vercel | Next.js déployé à chaque merge, CDN mondial, SSL automatique, URL de préversion par pull request |
| Traitements | VPS Hetzner, Docker Compose | Workers Python pour des traitements longs, derrière un reverse proxy Nginx avec SSL Certbot |
| Données | PostgreSQL managé + pgvector | Base, authentification et vector store sur une seule plateforme, restauration à un instant donné sur 7 jours |
| Réseau | Tailscale | Administration par réseau privé. Aucun port SSH exposé sur l'Internet public |
| Supervision | New Relic décrit en Terraform | Tableaux de bord, conditions d'alerte NRQL, sondes synthétiques et canaux de notification versionnés |
| Sauvegardes | Rôle Ansible dédié | Sauvegardes planifiées sur volume séparé, procédure de restauration écrite et rejouable |
| Disponibilité | IP flottante Hetzner | Bascule vers un serveur de secours sans changement DNS |
| CI/CD | GitHub Actions | 9 workflows : plan Terraform sur les changements d'infra, déploiement applicatif, contrôles de cohérence, synchronisation staging vers main |
Ce que j'ai livré
Une infrastructure que le client peut reconstruire, comprendre et exploiter sans moi.
Infrastructure décrite en Terraform
Serveurs, volumes, IP flottante, règles de pare-feu et clés SSH. L'environnement se reconstruit depuis le dépôt, sans clic dans une console.
9 rôles Ansible
Socle système, Docker, pare-feu, utilisateur de déploiement, volume de travail, réseau privé, agent de supervision, sauvegardes, IP flottante. Chaque rôle est rejouable sans effet de bord.
Observabilité en code
La supervision n'est pas configurée à la main dans une interface. Les tableaux de bord, les alertes NRQL et les sondes synthétiques sont versionnés avec le reste de l'infrastructure.
Pipelines et garde-fous
Le plan Terraform s'exécute sur toute modification d'infrastructure et doit être lu avant fusion. Des contrôles de cohérence bloquent les écarts entre le schéma de base et le code.
Secrets et accès
Chiffrement des variables sensibles avec Ansible Vault, rotation documentée, accès administrateur limité au réseau privé.
11 runbooks
De la restauration de sauvegarde au plan de reprise, en passant par la gestion d'incident et la montée en charge. L'équipe peut exploiter sans moi.
Les runbooks
Une infrastructure que personne ne sait redémarrer n'est pas livrée. 11 procédures ont été écrites avec le reste, en voici huit.
Les objectifs du document d'architecture
Les cibles écrites et validées avec le client avant la construction. Ce sont des engagements de conception, pas des mesures de production.
Déploiement
Moins de 5 min du push à la mise en ligne
Retour arrière
Moins de 2 min en cas d'incident
Alerte
Moins de 2 min après un incident de production
Sécurité
Aucun secret en clair, HTTPS partout, isolation par organisation
Où en est le projet
J'ai livré l'infrastructure du MVP pendant que le produit était en recette. Depuis, Waypoint est ouvert au public : on peut créer un compte et connecter son org Salesforce sur waypoint.better-call-us.com.
Le produit est celui de Better Call Us. Ma part, c'est le socle sur lequel il a démarré.
- Infrastructure reconstructible depuis le dépôt
- Supervision et alertes actives
- Sauvegardes planifiées et procédure de restauration écrite