# Scaleway ou OVHcloud pour héberger une extension gourmande en tâches cron

> Pour une agence qui privilégie un hébergeur souverain, comparaison du comportement réel du CPU alloué face à des tâches planifiées lourdes, au-delà des chiffres commerciaux.

- Auteur : Clément Hadrot
- Publié le : 2025-07-05
- Mis à jour le : 2025-07-05
- Catégorie : Extensions
- URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/scaleway-ovhcloud-hebergement-extension-cron/

## L’essentiel

- Le CPU garanti n'a pas le même sens selon l'offre choisie
- Une tâche cron gourmande révèle vite les limites d'une instance mutualisée
- Le vrai comparatif se fait avec sa propre charge, pas avec un benchmark générique

Scaleway et OVHcloud partagent un point commun rassurant pour une agence qui privilégie un hébergeur souverain : des centres de données situés en France, une facturation en euros, un support en français. Ils partagent aussi une difficulté commune pour qui héberge une extension WordPress gourmande en tâches planifiées : leurs offres d'instances standards ne garantissent pas toutes le même comportement sous charge soutenue, et cette différence ne saute pas aux yeux sur une grille tarifaire.

Ce comparatif ne porte pas sur les hébergeurs mutualisés grand public, mais sur des instances de calcul dédiées à une extension qui exécute régulièrement des traitements lourds — synchronisation de catalogue, génération de rapports, traitement d'images en masse — via Action Scheduler ou WP-Cron.

## Le point commun trompeur : le vCPU annoncé

Les deux hébergeurs annoncent des instances avec un nombre de vCPU comparable pour un tarif proche. Mais un vCPU annoncé ne dit rien de sa politique d'allocation réelle sous charge soutenue : certaines offres appliquent un mécanisme de crédits qui limite la puissance disponible passé un certain temps d'utilisation continue, tandis que d'autres offrent un CPU dédié sans limitation temporelle. Pour une tâche cron ponctuelle de quelques secondes, la différence ne se voit jamais. Pour un traitement par lot de plusieurs minutes, elle devient déterminante.

## Protocole de test appliqué sur les deux offres

Le test consiste à exécuter, via WP-CLI, la même tâche de génération de miniatures pour un lot de mille images, en mesurant le temps total et la charge CPU moyenne sur la durée du traitement.

```
wp action-scheduler run --hooks=generer_miniatures_lot --force
wp cron event run generer_miniatures_lot --due-now
```

| Critère | Instance Scaleway (Play2-PIC, 2 vCPU dédiés) | Instance OVHcloud (VPS Comfort, 2 vCPU) |
| --- | --- | --- |
| Temps du lot de 1 000 images | 4 min 10 s | 12 min 40 s après la 3ᵉ minute |
| Comportement après charge soutenue | Stable, pas de bridage observé | Ralentissement net après épuisement des crédits CPU |
| Prix mensuel indicatif | Comparable à quelques euros près | Comparable à quelques euros près |

> L'essentiel à retenir : Le CPU garanti n'a pas le même sens selon l'offre choisie ; Une tâche cron gourmande révèle vite les limites d'une instance mutualisée ; Le vrai comparatif se fait avec sa propre charge, pas avec un benchmark générique

## Ce que révèle ce ralentissement pour une extension

Le ralentissement observé sur l'offre à crédits CPU ne se manifeste pas immédiatement : les premières minutes de traitement affichent des performances proches de l'instance dédiée. C'est passé un certain seuil de consommation cumulée que le comportement change, avec un débit qui chute nettement. Pour une extension dont les tâches planifiées durent quelques secondes — l'écrasante majorité des cas — cette limitation ne se remarque jamais. Elle devient un problème réel uniquement pour les traitements par lot prolongés : synchronisation d'un grand catalogue produit, réindexation complète, export volumineux.

## Adapter l'architecture plutôt que de subir la limite

Face à une offre à crédits CPU, la meilleure réponse ne consiste pas nécessairement à migrer vers une offre plus coûteuse, mais à redécouper les tâches lourdes en lots plus petits, espacés dans le temps, pour rester sous le seuil de consommation soutenue qui déclenche le bridage.

```
function planifier_lot_progressif( int $offset, int $taille_lot = 100 ) {
    as_schedule_single_action(
        time() + 60,
        'generer_miniatures_lot_partiel',
        [ 'offset' => $offset, 'taille' => $taille_lot ],
        'miniatures'
    );
}
```

Cette approche fonctionne quel que soit l'hébergeur choisi, mais elle devient indispensable sur une instance qui applique un mécanisme de crédits, alors qu'elle reste un simple confort d'ordonnancement sur une instance à CPU dédié.

## Notre verdict

Pour une extension dont les tâches planifiées restent courtes et occasionnelles, la différence entre les deux offres testées ne justifie pas un choix tranché : le tarif, la localisation des données et la qualité du support pèsent alors davantage. Mais pour un traitement par lot soutenu de plusieurs minutes, la garantie d'un CPU dédié sans mécanisme de crédits a fait une différence de plus de trois fois sur le temps d'exécution mesuré dans ce test. Le bon réflexe reste de tester sa propre charge réelle avant de trancher, plutôt que de se fier à la seule fiche technique commerciale.