Questions fréquentes

Les sauvegardes sont automatisées et au moins une copie est conservée hors du serveur, là où le site ne peut pas la supprimer. Leur fréquence dépend de la perte de données acceptable, plus élevée pour une boutique que pour un site vitrine. La restauration est testée régulièrement : une sauvegarde jamais restaurée n’est pas une garantie. Voir notre guide de politique de sauvegarde.

La disponibilité du site et de ses parcours clés, et pas seulement de la page d’accueil, l’expiration du certificat et du nom de domaine, et les ressources du serveur : processeur, mémoire, espace disque. Des alertes se déclenchent avant la saturation, pour agir avant la panne.

Par des alertes automatiques sur les signaux qui précèdent une panne visible : erreurs serveur, erreurs applicatives, tâches planifiées en échec, échanges avec d’autres logiciels qui échouent, connexions anormales. L’incident est alors souvent traité avant d’être remarqué par les utilisateurs.

Les journaux de l’application et du serveur permettent de comprendre la cause d’un incident au lieu de la deviner, et de retracer les actions sensibles : connexions, changements de droits, installations d’extensions. Ils sont conservés pour une durée définie et ne doivent jamais contenir de mots de passe, de clés ni de données bancaires.

Une lenteur soudaine est souvent liée à une mise à jour, un pic de trafic, une requête lente ou un problème serveur. Ce n’est généralement pas aléatoire mais déclenché par un changement récent. Un diagnostic permet d’identifier rapidement la cause réelle.

Un site qui plante régulièrement révèle un problème structurel : surcharge serveur, bug applicatif ou conflit technique. Ce type d’instabilité nécessite une analyse des logs et une correction des causes profondes, pas seulement des correctifs temporaires.

Une application ne bug jamais « sans raison ». Les problèmes viennent souvent de conditions spécifiques non prévues, de dette technique ou d’effets de bord. Un audit permet d’identifier les causes invisibles et de stabiliser durablement l’application.

Après une mise à jour de WordPress, des incompatibilités entre plugins, thème ou version PHP peuvent casser le site. Sans tests préalables, ces conflits sont fréquents mais généralement réversibles avec une intervention rapide.

Les erreurs 500, 502 ou 503 indiquent un problème côté serveur : bug applicatif, surcharge ou mauvaise configuration. Elles impactent directement le SEO et l’expérience utilisateur. L’analyse des logs permet généralement d’identifier rapidement la cause.

Les formulaires sont ciblés par des bots qui détectent les champs et envoient des requêtes automatisées. Sans protections adaptées (honeypot, rate limiting, captcha…), ils deviennent facilement exploitables. Un bon système peut réduire le spam de plus de 90 %.

Une indisponibilité intermittente est souvent liée à une surcharge, un problème serveur ou une erreur applicative. Même si elle semble aléatoire, elle est généralement déclenchée par des conditions précises qu’un diagnostic permet d’identifier.

Oui. Nous développons un thème propre à votre site, plutôt qu’un thème du marché chargé de fonctions inutiles. Les fonctionnalités spécifiques sont développées dans des extensions maison, et la sécurité comme les connexions à vos outils sont prévues dès la conception.

Par l’API REST de WooCommerce et celle de l’ERP : les produits, prix et stocks descendent de l’ERP vers la boutique, les commandes et les clients remontent vers l’ERP. La faisabilité dépend de l’API de votre ERP, que nous vérifions au cadrage.

Chaque plugin est une dépendance de plus à mettre à jour et une faille possible. Un plugin désactivé reste du code présent sur le serveur. Quand une fonctionnalité est propre à votre activité, une extension dédiée est souvent plus sûre qu’une pile de plugins.

Couche par couche : serveur et réseau, comptes avec double authentification, mises à jour suivies, configuration et fichiers protégés, sauvegardes externes testées. Un plugin de sécurité complète ce travail, il ne le remplace pas.

Oui. Nous commençons par un audit WordPress pour mesurer l’état des extensions, des performances et de la sécurité. Nous intervenons aussi en marque blanche pour les agences.

Symfony est adapté lorsqu’un projet exige une architecture claire, des traitements métier spécifiques, des intégrations avec d’autres logiciels et un cadre de développement durable.

Oui, c’est un cas fréquent. Un audit établit d’abord l’état du code, de l’architecture, des tests et des dépendances, puis nous organisons une reprise progressive de l’application.

Progressivement, version majeure par version majeure : passer d’abord à la dernière version mineure de sa branche, corriger les dépréciations, mettre à niveau PHP et les dépendances, puis changer de version majeure, avec des tests à chaque étape.

Rarement. Le vrai enjeu est souvent de rendre l’existant fiable, compréhensible et exploitable, par un refactoring progressif. Un audit permet de décider entre amélioration ciblée, refonte partielle ou refonte complète.

Oui. Nous cartographions d’abord les flux de données, auditons les API disponibles, développons un pont entre les logiciels, puis le supervisons en production.

D’autres modes d’échange existent parfois : exports, webhooks ou fichiers. L’audit des API vérifie la faisabilité avant tout développement, pour ne pas engager un projet qui ne pourrait pas aboutir.

Oui. Nous concevons des API REST, notamment avec API Platform dans un environnement Symfony, lorsque l’API devient un composant central du système.

La supervision détecte les erreurs d’échange, et la maintenance adapte le connecteur aux évolutions de l’API. C’est pourquoi une intégration se prévoit avec son suivi en production.

Oui. Nous intégrons une API SMS pour les notifications, les alertes et les codes de connexion, avec le suivi de la délivrance de chaque message.

En traitant des données non structurées (emails, PDF, messages), en prenant des décisions simples (routage, qualification, priorités) et en déclenchant des actions dans vos outils. Par exemple : extraction des données de factures, aide à la saisie ou au contrôle.

Oui. Les agents s’appuient sur vos API, vos événements et vos données pour déclencher des actions réelles : création d’enregistrement, notification, tâche ou synchronisation. Il ne s’agit pas d’un outil isolé de plus.

Par des garde-fous : journaux, seuils, reprise manuelle et validation humaine lorsque c’est nécessaire. L’automatisation doit rester traçable et mesurable.

Par les processus, pas par l’outil. Un cadrage identifie les tâches répétitives qui absorbent du temps, les données disponibles et les actions à automatiser dans votre système existant.