Cloud API-first : tout est automatisable (et pourquoi)

Pourquoi peut-on créer 100 serveurs cloud en 30 secondes avec un script, alors qu’il faudrait des heures pour faire la même chose manuellement ? La réponse tient en deux mots : API-first. Ce guide vous explique ce principe fondamental du cloud computing, comment il fonctionne chez Outscale, et pourquoi il change tout pour l’automatisation de votre infrastructure.

Ce que vous allez apprendre

• Comprendre le principe API-first et pourquoi c’est la base du cloud moderne
• Comment fonctionne l’authentification (access keys) pour piloter le cloud par code
• Connaître les outils qui exploitent ces API : CLI, SDK, Terraform
• Mesurer les avantages concrets de l’automatisation vs l’approche console

Prérequis : connaître les bases du cloud computing. Si vous débutez, commencez par Qu’est-ce que le cloud ?.

Le cloud, c’est du logiciel qui pilote du matériel

L’infrastructure traditionnelle : des humains partout

Imaginez que vous devez commander un nouveau serveur dans un datacenter classique :

1. Vous remplissez un bon de commande (papier ou ticket)
2. Un technicien vérifie le stock de serveurs disponibles
3. Il installe physiquement le serveur dans un rack
4. Il branche les câbles réseau et électriques
5. Un autre technicien configure le système d’exploitation
6. Quelqu’un vous envoie un email avec les accès

Délai typique : quelques jours à plusieurs semaines. Et pour créer 10 serveurs identiques ? Multipliez le temps par 10.

Le cloud : des programmes qui font le travail

Dans le cloud, ce processus est entièrement automatisé. Quand vous cliquez sur “Créer une VM” dans Cockpit (la console web d’Outscale), voici ce qui se passe réellement :

1. Votre clic envoie une requête HTTP à l’API Outscale
2. L’API vérifie vos droits (avez-vous le droit de créer une VM ?)
3. L’API orchestre la création : allocation de ressources, configuration réseau, démarrage
4. L’API vous renvoie une réponse avec les informations de votre VM

Le point crucial : la console web n’est qu’une interface graphique qui appelle l’API. Vous pourriez faire exactement la même chose avec un script, un outil en ligne de commande, ou du code.

L'analogie du restaurant

Pensez à un restaurant. La console web, c’est comme commander au serveur qui note sur son carnet. L’API, c’est comme avoir accès direct à la cuisine : vous pouvez passer commande vous-même, en masse, et automatiquement. Le résultat est le même (votre plat), mais la méthode est plus efficace à grande échelle.

Le principe API-first : tout est pilotable par code

Qu’est-ce qu’une API ?

Une API (Application Programming Interface — Interface de Programmation d’Application) est un contrat entre deux logiciels. Elle définit :

• Quelles actions sont possibles (créer une VM, lister les volumes, supprimer un réseau…)
• Quels paramètres chaque action accepte (taille du disque, région, nom…)
• Quel format utiliser pour communiquer (généralement JSON via HTTP)
• Comment s’authentifier (prouver qu’on a le droit d’agir)

Concrètement, une API cloud vous permet d’écrire un programme qui crée, modifie ou supprime des ressources d’infrastructure — exactement comme si un humain cliquait dans la console.

Pourquoi “API-first” ?

Le terme API-first signifie que l’API n’est pas un ajout tardif, mais la fondation sur laquelle tout le reste est construit :

Composant	Rôle	Utilise l’API ?
API	Cœur du système, expose toutes les opérations	C’est l’API elle-même
Console web (Cockpit)	Interface graphique pour humains	✅ Appelle l’API en arrière-plan
CLI (osc-cli, oapi-cli)	Ligne de commande pour scripts	✅ Appelle l’API
SDK (Python, Go, Java…)	Bibliothèques pour développeurs	✅ Appelle l’API
Terraform	Infrastructure as Code	✅ Appelle l’API via le provider

Glissez pour voir

Tout passe par l'API

Chez Outscale, comme chez tous les cloud providers modernes, 100% des opérations passent par l’API. Cockpit n’a aucun “pouvoir spécial” — il utilise exactement les mêmes endpoints API que vos scripts. Si vous pouvez le faire dans Cockpit, vous pouvez l’automatiser.

L’API Outscale en bref

L’API Outscale (OAPI) est une API REST qui expose des actions pour gérer toutes les ressources cloud :

Catégorie	Exemples d’actions	Ce qu’elles font
Compute	CreateVms, ReadVms, DeleteVms	Gérer les machines virtuelles
Storage	CreateVolume, ReadVolumes, LinkVolume	Gérer les volumes de stockage
Network	CreateNet, CreateSubnet, CreateSecurityGroup	Gérer les réseaux virtuels
Identity	CreateAccessKey, ReadAccessKeys	Gérer les clés d’accès
Images	CreateImage, ReadImages	Gérer les images machine (OMI)

Glissez pour voir

Chaque action suit un pattern prévisible :

• Create* : créer une ressource
• Read* : lister ou obtenir des informations
• Update* : modifier une ressource existante
• Delete* : supprimer une ressource

Comment s’authentifier auprès de l’API

Le problème : prouver son identité à une machine

Quand vous vous connectez à Cockpit, vous utilisez un email et un mot de passe. Mais un script ne peut pas “taper” un mot de passe — il faut un autre mécanisme.

La solution : les Access Keys

Outscale (comme AWS et d’autres clouds) utilise un système d’Access Keys composé de deux parties :

Élément	Format	Rôle	Analogie
Access Key ID (AK)	AKIAIOSFODNN7EXAMPLE	Identifie le compte	Votre numéro de carte bancaire
Secret Key (SK)	Chaîne longue secrète	Prouve l’identité	Le code PIN de la carte

Glissez pour voir

La Secret Key est... secrète !

La Secret Key ne doit jamais être partagée, commitée dans Git, ou affichée en clair. Elle permet de signer des requêtes en votre nom. Si quelqu’un l’obtient, il peut agir sur votre infrastructure comme s’il était vous.

Chez Outscale, la Secret Key n’est visible qu’une seule fois lors de la création. Si vous la perdez, vous devez créer une nouvelle Access Key.

Comment ça fonctionne concrètement

Quand vous envoyez une requête à l’API Outscale, voici ce qui se passe :

1. Vous construisez la requête

   Par exemple : “Je veux créer une VM de type tinav5.c1r1p2 dans la sous-région eu-west-2a”

2. Vous signez la requête avec votre Secret Key

   Un algorithme cryptographique (HMAC-SHA256) génère une signature unique à partir de :

   • Le contenu de votre requête
   • La date et l’heure
   • Votre Secret Key

3. Vous envoyez la requête avec la signature

   L’en-tête HTTP contient votre Access Key ID + la signature calculée

4. L’API vérifie la signature

   Outscale possède une copie de votre Secret Key. Il recalcule la signature et vérifie qu’elle correspond. Si oui, vous êtes authentifié.

Vous n'avez pas à faire ça manuellement

En pratique, vous n’avez jamais à calculer les signatures vous-même. Les outils comme osc-cli, les SDK, et Terraform le font automatiquement. Vous configurez vos clés une fois, et c’est transparent ensuite.

Créer et gérer ses Access Keys

Les Access Keys se gèrent dans Cockpit (la console web Outscale) ou via l’API elle-même :

• Chaque compte peut avoir jusqu’à 10 Access Keys
• Une clé peut être ACTIVE (utilisable) ou INACTIVE (désactivée temporairement)
• Il est recommandé de renouveler ses clés régulièrement (tous les 3-12 mois)
• On peut définir une date d’expiration pour forcer le renouvellement

Rotation des clés

Outscale affiche un avertissement dans Cockpit si votre Access Key a plus de 3 mois, et un avertissement critique après 12 mois. C’est une bonne pratique de sécurité de les renouveler régulièrement.

Les outils qui exploitent l’API

L’API est puissante, mais envoyer des requêtes HTTP signées manuellement serait fastidieux. Heureusement, des outils simplifient l’utilisation.

Cockpit : la console web d’Outscale

Cockpit est l’interface graphique d’Outscale. Idéale pour :

• Découvrir les services et explorer son infrastructure
• Effectuer des opérations ponctuelles
• Visualiser l’état de ses ressources

Limitations : impossible d’automatiser, pas de reproductibilité, risque d’erreurs manuelles.

La ligne de commande : osc-cli et oapi-cli

Outscale propose deux CLI officiels :

CLI	Statut	Utilisation
osc-cli	Maintenance (bugs corrigés, pas de nouvelles fonctionnalités)	API Outscale + APIs compatibles AWS
oapi-cli	Actif (recommandé)	API Outscale native

Glissez pour voir

Exemple concret — Lister vos VMs avec osc-cli :

# Configuration préalable dans ~/.osc/config.json
osc-cli api ReadVms

Exemple concret — Créer un volume de 50 Go :

osc-cli api CreateVolume \
  --SubregionName eu-west-2a \
  --Size 50 \
  --VolumeType gp2

Pourquoi utiliser la CLI ?

La CLI permet d’enchaîner des commandes dans des scripts shell, de les versionner dans Git, et de les réutiliser. C’est le premier pas vers l’automatisation.

Les SDK : Python, Go, Java…

Pour intégrer Outscale dans vos applications, des SDK (Software Development Kits) sont disponibles :

Langage	SDK	Cas d’usage
Python	osc-sdk-python	Scripts d’automatisation, Lambda-like
Go	osc-sdk-go	Outils performants, microservices
Java	osc-sdk-java	Applications d’entreprise

Glissez pour voir

Exemple Python — Lister les VMs :

from osc_sdk_python import Gateway

# Configuration des credentials
gw = Gateway(**{
    "profile": "default",
    "region": "eu-west-2"
})

# Appel API
result = gw.ReadVms()
for vm in result.get("Vms", []):
    print(f"VM: {vm['VmId']} - État: {vm['State']}")

Terraform : l’Infrastructure as Code

Terraform est l’outil de référence pour déclarer son infrastructure sous forme de code. Outscale fournit un provider Terraform officiel.

Exemple Terraform — Déclarer une VM :

# Configuration du provider Outscale
terraform {
  required_providers {
    outscale = {
      source  = "outscale/outscale"
      version = "~> 1.0"
    }
  }
}

provider "outscale" {
  region = "eu-west-2"
  # Access keys lues depuis les variables d'environnement
  # OSC_ACCESS_KEY et OSC_SECRET_KEY
}

# Déclaration d'une VM
resource "outscale_vm" "web_server" {
  image_id     = "ami-12345678"  # OMI Ubuntu
  vm_type      = "tinav5.c1r1p2"
  subregion_name = "eu-west-2a"

  tags {
    key   = "Name"
    value = "web-server-prod"
  }
}

Pour appliquer cette configuration :

terraform init    # Télécharge le provider Outscale
terraform plan    # Prévisualise les changements
terraform apply   # Crée réellement la VM

Terraform = reproductibilité

Avec Terraform, votre infrastructure est décrite dans des fichiers. Vous pouvez recréer un environnement identique en une commande, le versionner dans Git, et le reviewer comme du code applicatif.

Pourquoi l’API-first change tout

Comparaison : manuel vs automatisé

Critère	Approche console (manuelle)	Approche API (automatisée)
Créer 1 serveur	5 minutes de clics	30 secondes
Créer 100 serveurs	~8 heures (si vous tenez)	30 secondes
Reproduire un environnement	Impossible exactement	Identique à chaque fois
Documenter l’infrastructure	Screenshots, wiki obsolète	Le code EST la documentation
Revenir en arrière	Impossible ou très risqué	git revert + terraform apply
Audit des changements	”Qui a fait ça ?!”	Historique Git complet
Erreurs humaines	Fréquentes (fatigue, distraction)	Éliminées (le code ne se trompe pas)

Glissez pour voir

Les bénéfices concrets

1. Reproductibilité

   Un script ou une configuration Terraform produit toujours le même résultat. Fini le “ça marchait sur mon environnement de test” — dev, staging et prod sont identiques.

2. Scalabilité

   Besoin de 50 serveurs pour un pic de charge ? Une boucle dans votre code. Besoin de revenir à 5 serveurs ? Une autre exécution.

3. Versionnement

   Votre infrastructure est du code. Elle vit dans Git, avec des commits, des branches, des pull requests, des reviews.

4. Collaboration

   Plusieurs personnes peuvent travailler sur l’infrastructure en parallèle, merger leurs changements, et avoir une source de vérité unique.

5. Disaster Recovery

   Si tout est détruit, vous terraform apply et votre infrastructure renaît. Essayez de faire ça avec des screenshots de console.

Le piège de la console

La console est séduisante : visuelle, intuitive, rassurante. Mais elle crée une dette technique invisible :

• Personne ne sait exactement comment l’infrastructure a été configurée
• Les changements ne sont pas tracés
• Impossible de reproduire l’environnement ailleurs
• Les erreurs manuelles s’accumulent

La règle d'or

Utilisez la console pour explorer et comprendre. Utilisez l’API (via CLI, SDK, Terraform) pour construire et opérer.

La console est un excellent outil d’apprentissage et de débogage ponctuel. Mais en production, tout devrait passer par du code.

Les pièges courants et comment les éviter

Piège n°1 : “Je commence par Cockpit, j’automatiserai plus tard”

Risque : “plus tard” n’arrive jamais, et vous vous retrouvez avec une infrastructure impossible à reproduire.

Solution : commencez par Terraform dès le premier serveur. La courbe d’apprentissage est rapide, et vous construisez de bonnes habitudes dès le départ.

Piège n°2 : “Je stocke mes Access Keys dans le code”

Risque : vos clés se retrouvent dans Git, sont partagées involontairement, et quelqu’un compromet votre infrastructure.

Solution : utilisez des variables d’environnement (OSC_ACCESS_KEY, OSC_SECRET_KEY) ou un gestionnaire de secrets.

Piège n°3 : “J’ai un seul jeu d’Access Keys pour tout”

Risque : si ces clés sont compromises, l’attaquant a accès à tout.

Solution : créez des Access Keys dédiées par environnement, par outil, voire par pipeline CI/CD. Appliquez le principe du moindre privilège.

Piège n°4 : “L’API, c’est compliqué, je reste sur Cockpit”

Risque : vous passez à côté de 90% de la puissance du cloud.

Solution : commencez petit. Un osc-cli api ReadVms pour lister vos VMs. Puis un script qui crée une ressource. La montée en compétence est progressive.

Checklist : adopter l’approche API-first

Pour démarrer

• Créer une Access Key dédiée à l’automatisation (pas celle de Cockpit)
• Installer osc-cli ou oapi-cli sur votre poste
• Configurer les credentials dans ~/.osc/config.json
• Tester une commande simple : osc-cli api ReadVms

Pour aller plus loin

• Installer Terraform et le provider Outscale
• Écrire votre première ressource en Terraform
• Versionner dans Git votre configuration
• Supprimer les ressources créées manuellement et les recréer via code

Pour l’équipe

• Documenter la convention de nommage des Access Keys
• Mettre en place la rotation automatique des clés (tous les 90 jours)
• Former l’équipe aux bases de Terraform
• Interdire les modifications manuelles en production

À retenir

Les 6 points essentiels

1. API-first = tout est pilotable par code. La console n’est qu’une interface graphique qui appelle l’API en arrière-plan.

2. L’API Outscale expose des actions (CreateVms, ReadVolumes, DeleteNet…) accessibles via HTTP REST avec authentification par signature.

3. Les Access Keys (Access Key ID + Secret Key) permettent à vos scripts de s’authentifier. La Secret Key est secrète et ne doit jamais être partagée.

4. Plusieurs outils exploitent l’API : la CLI (osc-cli, oapi-cli), les SDK (Python, Go), et Terraform pour l’Infrastructure as Code.

5. L’automatisation apporte reproductibilité, scalabilité, versionnement, et élimine les erreurs manuelles. C’est indispensable en production.

6. La console pour apprendre, l’API pour construire. Explorez avec Cockpit, déployez avec Terraform.

Prochaines étapes

Régions et sous-régions Choisissez où déployer vos ressources

×

📖 Voir la documentation →