Le jour où j'ai déployé une API pour 0,02 € par mois
Un client avait besoin d'un formulaire de contact sur son site Next.js hébergé chez Vercel. Rien de fou. Recevoir un nom, un email, un message, l'envoyer par mail via SendGrid. Le genre de truc qu'on fait en 30 minutes.
J'ai créé une Azure Function App en .NET isolated worker, écrit la fonction, fait un `dotnet publish`, déployé via Azure CLI. Du premier coup de clavier au moment où le formulaire envoyait des mails en production : 15 minutes. Le coût mensuel ? 0,02 €. Pas 2 euros. Deux centimes.
L'architecture était simple :
``` Client → Vercel (Next.js) → Azure Function App → SendGrid → Email ```
Quatre composants. Zéro serveur à gérer. Et une facture Azure qui ne dépasse pas le prix d'un café par an.
C'est ce genre d'expérience qui m'a convaincu qu'Azure est un choix solide pour les PME européennes. Pas parce que c'est parfait, rien ne l'est, mais parce que le ratio coût/résultat est difficile à battre quand on sait où mettre les pieds.
Le consumption plan : commencez par là
Le modèle économique d'Azure Functions sur un consumption plan est redoutable. Vous payez par exécution. Pas de serveur allumé 24h/24 à attendre des requêtes. Si personne n'appelle votre API un dimanche, vous payez zéro.
Les premiers million d'exécutions par mois sont gratuits. Pour une PME, ça couvre la majorité des cas d'usage. Un webhook, une API interne, un traitement de fichiers, tout ça tourne pour quelques centimes.
Mon conseil pratique : commencez avec un consumption plan. Quand votre Function App commence à coûter plus de 30 €/mois, basculez sur un plan dédié. Avant ça, vous optimisez un problème qui n'existe pas.
Le piège classique, c'est de partir directement sur un App Service Plan B1 ou B2 "au cas où". J'ai vu des clients payer 50 €/mois pour des workloads qui auraient coûté 3 € en consumption. Résistez à l'envie de sur-provisionner.
Le modèle isolated worker en .NET : le bon choix
Depuis .NET 5, Microsoft pousse le modèle isolated worker pour les Azure Functions. Et ils ont raison. Le modèle in-process est en fin de vie.
L'isolated worker vous donne le contrôle sur le runtime. Vous gérez votre propre `Program.cs`, votre injection de dépendances, votre middleware. C'est du .NET standard. Si vous savez construire une API ASP.NET Core, vous savez construire une Function App en isolated worker.
Concrètement, j'utilise .NET 8 (bientôt .NET 10) avec le package `Microsoft.Azure.Functions.Worker`. La structure est propre : un `Program.cs` pour le bootstrap, des classes de fonctions avec des attributs de trigger, et c'est tout. Pas de magie noire.
RGPD et région West Europe
Si vous travaillez avec des clients européens, la question du RGPD revient systématiquement. "Où sont stockées nos données ?" C'est légitime.
Azure rend ça simple. Vous choisissez la région West Europe (Pays-Bas) ou France Central (Paris) et vos données restent en Europe. Point. Pas de transfert transatlantique, pas de clauses contractuelles à négocier.
Je déploie tout en West Europe par défaut. La latence est excellente depuis la France, la Belgique, le Maroc. Et quand un client me demande une preuve de conformité, je lui montre la configuration Azure, la région est inscrite noir sur blanc.
Azure DevOps pour le CI/CD
GitHub Actions est à la mode. Mais pour les PME qui sont déjà sur Microsoft 365, Azure DevOps reste un choix cohérent. Tout est au même endroit : les repos, les pipelines, les boards.
Mon pipeline type pour une Function App :
- Push sur `main`
- Build .NET + tests
- `dotnet publish` en mode Release
- Déploiement vers Azure via une service connection
Quatre étapes. Le YAML fait 40 lignes. Ça tourne en 2 minutes.
L'avantage sous-estimé d'Azure DevOps, c'est les 1800 minutes de build gratuites par mois sur les agents hébergés. Pour une PME qui déploie quelques fois par semaine, c'est largement suffisant.
App Insights : l'observabilité sans prise de tête
J'ai longtemps négligé le monitoring. "Ça marche, pourquoi surveiller ?" Jusqu'au jour où une Function App d'un client IoT, un industriel dans le packaging de machines, a commencé à timeout sur certains messages MQTT sans que personne ne s'en rende compte pendant trois jours.
Depuis, Application Insights est activé sur tout. Le SDK s'intègre en une ligne dans le `Program.cs`. Vous avez les temps de réponse, les exceptions, les dépendances, les traces, tout.
Le Live Metrics est un vrai plaisir. Vous voyez en temps réel ce qui se passe dans votre app. Quand vous déployez en production un vendredi à 17h (on l'a tous fait), c'est rassurant d'avoir une vue en direct.
Pour le client IoT, on a configuré des alertes sur le nombre de failures par minute. Le jour où un edge device a commencé à envoyer des payloads malformés, on a été prévenu en moins de 5 minutes. Avant App Insights, ça prenait des jours.
Key Vault : ne mettez plus jamais un secret dans appsettings.json
Chaque projet JADEV utilise Azure Key Vault pour les secrets. Clés API, connection strings, tokens, tout passe par Key Vault.
L'intégration avec les Function Apps est native. Vous référencez un secret dans la configuration de l'app avec la syntaxe `@Microsoft.KeyVault(SecretUri=...)` et c'est résolu au démarrage. Pas de code spécial. Pas de bibliothèque tierce.
Le vrai avantage, c'est la rotation. Vous changez un secret dans Key Vault, vous redémarrez l'app, c'est fait. Pas de déploiement. Pas de commit avec un mot de passe en clair dans l'historique Git (j'ai vu des choses...).
Azure vs AWS : choisissez l'écosystème
On me pose souvent la question. "Azure ou AWS ?" Ma réponse est toujours la même.
Azure gagne quand votre client est déjà sur Microsoft 365. L'intégration avec Entra ID (ex-Azure AD), les licences, le SSO, tout est fluide. Vous n'avez pas à convaincre le DSI d'ouvrir un compte chez un autre fournisseur.
AWS gagne sur la performance brute de Lambda. C'est factuel. Les cold starts sont plus courts, la documentation est plus mature sur certains services.
Mais voilà : choisissez l'écosystème, pas le benchmark. Si votre client utilise Outlook, Teams et SharePoint, Azure est le choix naturel. Si votre client est une startup tech sur Linux avec des développeurs qui respirent Terraform, allez sur AWS.
Le pire choix, c'est de mélanger les deux sans raison. J'ai vu un projet avec l'auth sur Azure, le compute sur AWS et le stockage sur GCP. Le coût de maintenance était délirant.
Les erreurs que j'aurais aimé éviter
En vrac, après des dizaines de déploiements :
- Ne pas activer les logs de diagnostic dès le premier jour. Quand ça plante en prod, c'est trop tard pour les activer.
- Utiliser un storage account par Function App. Ça coûte rien et ça évite les collisions de lease blob.
- Tester les cold starts avant de promettre un SLA. Sur un consumption plan, le premier appel après 20 minutes d'inactivité peut prendre 5 à 10 secondes en .NET.
- Mettre un budget alert à 10 € sur chaque souscription. J'ai eu un stagiaire qui a laissé tourner un cluster AKS pendant un week-end. 180 € pour rien.
Conclusion pragmatique
Azure n'est pas parfait. Le portail est lent, la documentation est parfois incohérente, et la facturation peut surprendre si on ne surveille pas.
Mais pour une PME européenne qui veut déployer des APIs, des traitements asynchrones ou des workloads IoT, c'est un choix solide. Le consumption plan permet de démarrer sans risque financier. La région West Europe règle la question RGPD. Et l'écosystème .NET isolated worker est enfin mature.
Commencez petit. Un formulaire de contact. Un webhook. Une fonction de traitement de fichiers. Mesurez le coût réel. Et décidez ensuite si vous montez en charge.
C'est comme ça qu'on construit des architectures durables. Pas en lisant des whitepapers, mais en déployant des trucs qui marchent.