Bienvenue à la partie 6 de notre série de décomposition SaaS en public.

Nous avons couvert :

• Le problème
• Le produit
• Le marché
• La tarification
• Les premiers utilisateurs

Il est maintenant temps de répondre :

« Comment allons-nous réellement construire cette chose ? »

La bonne nouvelle ?
Vous pouvez construire cela sans plugins, sans gros serveurs, et sans exploser votre budget.

Décomposons cela.

Le Flux du Système Central

Le produit doit :

1. Se connecter à un site WordPress en utilisant l’API REST (via une clé API générée par l’utilisateur)
2. Explorer toutes les pages/articles publiés, récupérer le HTML brut (DOM)
3. Extraire les URL des images et créer une liste des “images utilisées”
4. Comparer cette liste à la bibliothèque de médias via l’API REST
5. Supprimer les images non utilisées via l’API et les stocker dans un compartiment cloud séparé

Ce n’est pas un travail pour un serveur encombrant.
C’est un travail pour une architecture sans serveur.

Pourquoi le Sans Serveur a du Sens

Des plateformes comme AWS Lambda, Cloudflare Workers ou Vercel Functions vous permettent d’exécuter du code à la demande — et de ne payer que pour ce que vous utilisez [1].

Avantages :

• Pas de coûts d’inactivité
• Évolutivité instantanée
• Unités de déploiement plus petites (chaque fonction a un seul but)

Notre backend pourrait être composé de micro-fonctions :

• Scanner le site
• Extraire les références médias
• Comparer à la bibliothèque
• Exécuter les suppressions
• Télécharger vers le stockage

Pour le stockage :

• Amazon S3 pour les 30 premiers jours
• Transition de cycle de vie vers S3 Glacier, puis Deep Archive [2][3][4]

Aperçu de la Pile Technologique

Extras optionnels :

• Scans programmés via AWS EventBridge [6]
• Tâches en arrière-plan via AWS SQS [7] ou Google Cloud Tasks [8]

Logique de Récupération : Pas si Difficile

Oui, récupérer des fichiers dans la bibliothèque de médias peut sembler complexe, mais c’est gérable.

Lors de la suppression, nous stockerions :

• Fichier original
• Toutes les tailles générées (miniature, moyenne, grande…)
• Métadonnées pertinentes (alt, titre, type MIME, éventuellement ID de pièce jointe original)

Lors de la restauration :

• Re-télécharger les fichiers via l’API REST
• Permettre au système de régénérer les tailles manquantes si nécessaire
• (Optionnellement) réassocier le fichier à un article ou un enregistrement

Même si une correspondance parfaite n’est pas toujours possible, les fichiers restaurés sont en sécurité dans la bibliothèque de médias — prêts à être utilisés à nouveau.

Estimations des Coûts d’Infrastructure

Voyons ce que cela pourrait coûter en termes réels. Ce ne sont pas des abstractions — elles sont basées sur les tarifs publiés par des fournisseurs de confiance :

De manière réaliste, vous pourriez faire fonctionner cette infrastructure pour bien moins de 30 €/mois pendant les premières étapes.

Combien de Temps Cela Prendrait-il pour Construire ?

Donnons une estimation réaliste du temps en heures, en supposant une équipe full-stack expérimentée.

Note : Ce sont purement indicatifs.
Le temps de développement réel dépend des compétences et de la structure de votre équipe.
Travailler avec des développeurs expérimentés qui comprennent le sans serveur, la pensée API-first et les internes de WordPress peut améliorer considérablement la vitesse et la qualité du code.

Coin Tech : Outils Optionnels qui Évoluent avec Vous

Si vous visez à évoluer ou à automatiser encore plus, ces technologies valent la peine d’être explorées :

• AWS EventBridge
  Utilisé pour déclencher des événements programmés comme des scans hebdomadaires ou des actions de stockage temporisées [6].
• AWS SQS (Simple Queue Service)
  Utile pour mettre en file d’attente des tâches comme les suppressions d’images, les transitions de stockage ou les récupérations [7].
• Google Cloud Tasks
  Une alternative à SQS pour mettre en file d’attente et gérer des tâches asynchrones dans Google Cloud [8].

Ces services ne sont pas obligatoires pour un MVP, mais ils aident à rendre votre produit évolutif, résilient et prêt pour l’avenir.

Réflexions Finales

C’est un exemple classique de SaaS « léger mais puissant » :

• Portée réduite
• Valeur réelle
• Coût faible
• Levier élevé

Et avec les bons choix — architecture sans serveur, intégration simple de l’API REST, et cycle de vie de stockage automatisé — vous pourriez le construire pour des centimes par dollar.

Dans la partie 7, nous partagerons quelque chose de différent :
Ce que nous avons choisi de ne pas construire, et pourquoi sauter des fonctionnalités peut réellement renforcer votre SaaS.

Restez à l’écoute.

Références

1. Tarification AWS Lambda
   https://aws.amazon.com/lambda/pricing/
2. Tarification du stockage Amazon S3 Standard
   https://aws.amazon.com/s3/pricing/
3. Tarification Amazon S3 Glacier
   https://aws.amazon.com/s3/storage-classes/glacier/
4. Tarification Amazon S3 Glacier Deep Archive
   https://aws.amazon.com/s3/storage-classes/glacier-deep-archive/
5. Tarification Supabase
   https://supabase.com/pricing
6. Documentation AWS EventBridge
   https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html
7. Documentation AWS SQS
   https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
8. Documentation Google Cloud Tasks
   https://cloud.google.com/tasks/docs
9. Tarification Resend Email
   https://resend.com/pricing