Questions fréquentes

À Saint-Herblain, près de Nantes, dans le datacenter Etix Ouest. Le matériel nous appartient et nous le gérons de bout en bout : nous ne sous-louons rien à un autre prestataire et nous ne pratiquons pas la sur-réservation de ressources. Vos données restent en France, et nos bureaux sont juste à côté des machines.

Notre offre d’hébergement →

Cela dépend de ce que vous voulez en faire. Notre offre de location démarre à 9 € HT par mois, engagement de 12 mois, nom de domaine en sus : elle comprend le site — vitrine ou boutique —, son hébergement et l’accès au support. Un projet sur-mesure fait l’objet d’un devis, et une mission de conseil se facture à partir de 1 000 € par jour, dégressif selon la durée.

La location de site →

Oui. Nous construisons sur des logiciels libres, précisément pour que vous gardiez votre liberté : le site, son code et son contenu vous appartiennent, et rien ne vous lie à nous techniquement.

Oui. Pour une création ou une refonte de site, vous choisissez librement votre hébergeur et votre formule d’hébergement. Nous les prenons tous en charge : notre code est standard, il ne dépend d’aucune infrastructure particulière et fonctionne partout. Notre propre hébergement est une option, jamais une condition — mais héberger ailleurs, c’est renoncer à tout ce qu’il apporte : sauvegarde automatique quotidienne, pare-feu applicatif, astreinte, garantie de rétablissement en 4 heures et support direct de l’équipe qui gère les machines.

Création de site internet →

Les données confiées font l’objet d’une sauvegarde automatique quotidienne et chaque site est protégé par un pare-feu applicatif. En heures ouvrées, le support répond au téléphone ; en dehors, une astreinte prend le relais. La garantie de temps de rétablissement est de 4 heures.

Hébergement et cloud →

Non. Le support téléphonique est gratuit et sans intermédiaire, de 9h à 12h et de 14h à 17h du lundi au vendredi. Vous parlez directement à quelqu’un qui connaît votre dossier : chez nous, un client est une personne identifiée.

Nous contacter →

Oui. La création de sites, le développement et l’hébergement se pilotent à distance, partout en France. Notre offre de fibre dédiée couvre également Rennes, Paris, Toulouse, Strasbourg, Marseille et le reste du territoire.

Fibre optique dédiée →

Non, et c’est important de le dire. La qualification juridique d’un traitement, l’analyse d’impact quand elle s’impose et la désignation d’un délégué à la protection des données relèvent d’un conseil juridique. Nous intervenons sur l’autre moitié : l’inventaire réel dans vos systèmes, la documentation qui en découle et les mesures techniques qui la rendent vraie.

Par l’inventaire, toujours. Tant qu’on ne sait pas quelles données existent, où elles sont et depuis quand, tout document de conformité est une hypothèse. C’est aussi l’étape qui produit les décisions les plus rentables : il y a presque toujours des données à supprimer, ce qui réduit d’autant le risque.

En France, sur notre propre infrastructure, à Saint-Herblain et dans d’autres centres de données français. Les seules lois qui s’y appliquent sont françaises et européennes. Nous sommes nous-mêmes soumis au RGPD et nous en appliquons les règles : vos données vous appartiennent, et nous ne les revendons pas.

Notre cloud →

Non, et c’est souvent le seul élément mis en place. Un bandeau ne vaut que par ce qu’il empêche : aucun traceur non essentiel ne doit être déposé avant consentement, le refus doit être aussi simple que l’acceptation, et le choix doit pouvoir se retirer. Beaucoup de sites déposent d’ailleurs des traceurs hérités d’outils qu’ils n’utilisent plus — le premier travail est de supprimer.

C’est la question qui met en défaut la plupart des procédures d’effacement. Une donnée supprimée d’une base reste dans les sauvegardes jusqu’au terme de leur propre cycle de rétention : la réponse admise est de documenter ce cycle et de garantir que la donnée ne sera pas réintroduite lors d’une restauration.

Sauvegarde distante →

Sur devis, selon le périmètre. Comme nos autres missions de conseil, cela peut prendre la forme d’un forfait quand l’objectif est clair, ou d’un accompagnement au jour quand le besoin se précise en avançant, sans engagement de durée.

Consulting DevOps →

Deux modes. Au forfait quand l’objectif est clair et que vous voulez un prix fixe — nous établissons alors un cahier des charges détaillé pour éviter les dérives. Au taux journalier quand le besoin est difficile à cadrer : à partir de 1 000 € par jour, dégressif selon la durée. À titre d’exemple, cinq jours de conseil en architecture cloud représentent 3 250 € HT, avec un compte rendu quotidien.

Consulting DevOps →

Non, nos missions sont sans engagement de durée. Beaucoup commencent par quelques jours d’état des lieux, ce qui permet aussi d’éprouver notre travail avant d’envisager un accompagnement plus long.

Non, et nous poserons la question du gain avant celle de la méthode. Découper un système résout des problèmes réels et en crée d’autres : plus de réseau, plus de pannes partielles, plus d’outillage à tenir. Il nous arrive de conclure qu’un monolithe mieux découpé est la bonne réponse — cela coûte moins cher et se maintient.

Avec elles. Un système d’information dont l’architecture n’est comprise que par un prestataire est un problème de plus, pas une solution. Nous apportons un regard extérieur et des profils seniors ; la main reste chez vous.

Par le métier plutôt que par la technique. Découper par couche — une brique pour la base, une pour les écrans — est intuitif mais rend chaque évolution fonctionnelle transverse. Nous cherchons les domaines qui ont leur propre vocabulaire et leurs propres règles : ce sont les frontières qui tiennent, et celles qui permettent de basculer un morceau sans réveiller le reste.

Développement d’applications →

Cela arrive souvent, et c’est plus simple à traiter. Si la question est de tenir la charge, d’absorber une panne ou de sortir d’un hébergement subi, elle relève de nos offres d’infrastructure plutôt que d’une mission d’architecture.

Serveurs privés →

Au forfait quand l’objectif est clair et que vous voulez un prix fixe — nous établissons alors un cahier des charges détaillé pour éviter les dérives. Au taux journalier quand le besoin est difficile à cadrer, ou quand vous voulez éprouver notre expertise avant un engagement long. C’est à partir de 1 000 € par jour, dégressif selon la durée.

Un forfait à partir de 8 000 € HT, avec en livrable un rapport et des recommandations actionnables classées par ce qu’elles coûtent et ce qu’elles évitent. Nous y regardons quatre choses que les chaînes de déploiement traitent rarement : les secrets, les dépendances, les droits des automates et les environnements de recette.

Non. Les missions vont de l’audit court à l’accompagnement durable, sans engagement de durée. C’est aussi ce qui permet de commencer petit : cinq jours de conseil en architecture cloud, par exemple, pour 3 250 € HT avec un compte rendu quotidien.

Rarement. Tant qu’on ne sait pas reconstruire une machine à l’identique, le reste est du bricolage : c’est par là que nous commençons. Et nous n’installerons pas de chaîne sur une organisation qui ne veut pas déployer plus souvent — si la décision de livrer reste soumise à un comité mensuel, la meilleure chaîne du monde attendra le comité.

Oui, et c’est souvent là que se joue le vrai sujet : découpage en domaines, séparation du métier et de la technique, choix entre monolithe et services. Le conseil en infrastructure et la façon dont l’application est écrite ne se traitent pas séparément.

Architecture du SI →

Oui, comme pour le reste de nos prestations : nos équipes sont à Nantes, nos clients sont dans toute la France. Les moments où la présence sur site apporte vraiment quelque chose — comprendre une organisation, voir les équipes travailler — se traitent en quelques journées ciblées.

Un audit DevSecOps complet, avec rapport et recommandations actionnables en livrable, fait l’objet d’un forfait à partir de 8 000 € HT. Si le besoin est plus difficile à cadrer, le conseil se facture à partir de 1 000 € par jour, dégressif selon la durée, sans engagement.

Consulting DevOps →

La taille ne protège de rien : les attaques les plus courantes sont automatisées et ne choisissent pas leur cible, elles balaient. En revanche le périmètre change beaucoup, et le conseil au jour permet de traiter l’essentiel sans engager un audit complet.

Le périmètre. Sécuriser un site, c’est le protéger lui : pare-feu applicatif, correction des failles, détection des fichiers compromis. Sécuriser un système d’information, c’est traiter tout le reste — postes, serveurs, messagerie, accès, sauvegardes — dont le site n’est qu’un élément.

Sécurisation de site web →

Seulement si elle est hors de portée. Un rançongiciel cherche activement les sauvegardes sur le réseau, parce qu’il sait que c’est ce qui décide du paiement. Une copie répliquée hors de vos locaux, sur une infrastructure distincte et supervisée, est la seule qui tienne.

Sauvegarde distante →

L’audit porte d’abord sur la configuration, l’exposition et les processus — c’est ce qui explique la grande majorité des incidents réels, et c’est moins coûteux à corriger. Si votre contexte demande un test d’intrusion en conditions réelles, dites-le nous : cela se cadre à part.

Au forfait quand l’objectif est clair — « migrer notre monolithe vers des microservices en trois mois » — avec un cahier des charges détaillé établi ensemble pour éviter les dérives, et un prix fixe. Au taux journalier quand le besoin se précise en avançant : à partir de 1 000 € par jour, dégressif selon la durée, sans engagement.

Consulting DevOps →

Presque jamais. Une refonte utile commence par distinguer ce qui pose réellement problème de ce qui fonctionne et qu’on remplacerait par habitude. Il arrive qu’une partie du système soit conservée telle quelle, et que le projet se réduise à deux ou trois domaines — pour un coût sans rapport avec le projet initial.

L’ordre. L’architecture établit l’état des lieux, la cible et la trajectoire : elle répond à « où aller et dans quel ordre ». La refonte est l’exécution de cette trajectoire — migration, cohabitation, reprise des données, décommissionnement. Beaucoup de projets commencent par la première et enchaînent sur la seconde.

Architecture du SI →

Oui, et il le faut : geler l’existant pendant deux ans n’est pas tenable pour une entreprise qui vit. C’est justement l’argument pour une refonte par étapes — chaque domaine basculé cesse d’évoluer des deux côtés, ce qui réduit progressivement le sujet au lieu de le laisser grossir.

Non, elles travaillent avec. Un système refait par un prestataire seul devient un système que vous ne maîtrisez pas — vous auriez changé de dépendance, pas résolu le problème. Nous apportons des profils seniors et un regard extérieur ; la main reste chez vous.

Un gestionnaire de contenu suffit dans la grande majorité des cas, et une formation vous rend autonome sur la mise à jour. Le sur-mesure devient nécessaire quand la demande est trop spécifique pour un CMS — et entre les deux, il y a le développement des modules qui manquent, qui règle beaucoup de situations sans tout reconstruire.

Développement d’applications métier →

Pour garantir la pérennité de votre solution et vous permettre de repartir sur des bases solides, avec nous ou sans nous. Un site bâti sur un outil propriétaire vous lie à celui qui le vend : le jour où vous voulez changer de prestataire, ou lui de stratégie, c’est votre problème.

Oui, c’est prévu par défaut : nos sites sont administrables depuis un navigateur, sur n’importe quel appareil connecté. Vous ajoutez, modifiez et supprimez du contenu, et nous vous formons à l’outil retenu.

Oui, et c’est souvent la bonne façon de s’y prendre : vous pouvez démarrer par un site mono-page et l’étendre plus tard, sans jeter le travail déjà réalisé. C’est ce que permet de construire sur un socle évolutif plutôt que sur un gabarit figé.

Création de site internet →

PHP et Symfony, Java, Go, Node.js ou TypeScript, en tenant compte des contraintes de votre environnement. Nous ne partons pas d’une technologie pour aller vers votre besoin : c’est à nous de nous adapter, pas l’inverse.

Trois besoins la justifient : fonctionner durablement hors connexion, accéder à des capteurs ou du matériel que le navigateur atteint mal, ou envoyer des notifications qui font partie du service. En dehors de ces cas, un site conçu pour le téléphone rend le même service pour bien moins cher — et sans demander une installation à vos utilisateurs.

Parce que c’est là que se trouve la valeur et la durée. L’écran change — technologie, mode, refonte ; les comptes, les règles métier et les données restent. Une API bien construite sert successivement un site, une application installable puis une application native, sans être refaite à chaque fois.

Non, et c’est une confusion coûteuse. Le contenu d’une application n’est pas indexé comme celui d’un site ; c’est d’ailleurs aussi vrai d’une application front de type SPA, dont le référencement est très complexe, souvent impossible. Si vous voulez être trouvé, il faut un site — l’application vient éventuellement en plus.

Application front SPA →

Sur devis, et l’écart entre les trois réponses est considérable : un site conçu pour le téléphone, une application installable et une application native publiée sur les magasins n’ont pas le même ordre de grandeur, ni le même coût récurrent. C’est pourquoi nous posons l’arbitrage avant le chiffrage.

C’est souvent le meilleur terrain pour une application installable : vos équipes s’en servent tous les jours, il n’y a personne à convaincre d’installer quoi que ce soit, et vous évitez le cycle de publication des magasins. Le sujet rejoint alors celui de l’outil métier.

Développement d’applications →

À partir de votre catalogue et de votre organisation : nombre de références, nombre de vitrines, structure des familles et des déclinaisons, règles de livraison, et lien éventuel avec un logiciel de gestion. L’outil s’adapte à votre besoin — et non l’inverse. Nous ne partons jamais de la technologie.

Oui, et même sans accès à la base de données de l’ancien site : nous écrivons alors les programmes qui vont chercher les produits directement sur les pages existantes et les réintègrent. C’est souvent la partie la plus longue du projet, et elle se chiffre à part.

La refonte SVVP →

C’est le risque principal d’une refonte de boutique, et il se traite en amont. Chaque fiche produit est une page qui peut être positionnée : les adresses sont conservées quand c’est possible, redirigées une à une quand ça ne l’est pas.

Référencement / SEO →

Sur devis, et le prix dépend beaucoup moins du nombre de produits que de trois choses : la structure du catalogue, les règles de livraison, et ce qu’il faut récupérer de l’existant. Décrivez-nous ces trois points et nous chiffrons — après les avoir regardés, pas avant.

Nos offres mutualisées reposent sur des ressources dédiées et garanties, et suffisent à la majorité des boutiques — le module LiteSpeed y accélère Prestashop comme Magento sans surcoût. Pour un gros catalogue ou un fort trafic, nous regardons ensemble si un serveur privé est plus adapté.

Hébergement mutualisé →

Non. Vous êtes libre de choisir votre hébergeur et votre formule d’hébergement : nous les prenons tous en charge, car notre code est standard et ne dépend d’aucune infrastructure particulière. Ce n’est pas une condition — contrairement à d’autres prestataires, nous ne cherchons pas à vous rendre dépendants. Sachez simplement qu’en hébergeant ailleurs, vous perdez tous les avantages de notre hébergement : la sécurisation, la sauvegarde quotidienne et nos garanties professionnelles.

Notre cloud nantais →

Oui : le site est le vôtre, le contenu vous appartient, et il n’y a ni redevance annuelle ni abonnement caché pour continuer à l’utiliser. C’est aussi pour cela que nous travaillons avec des outils libres — vous pouvez repartir avec, chez qui vous voulez.

Nos offres démarrent à 250 € HT et s’adaptent à votre budget. Ce qui fait varier le devis n’est presque jamais le graphisme : c’est le volume de contenu à produire ou à reprendre, et le nombre de fonctions qui sortent du standard.

Création de site internet →

Systématiquement. Ce n’est plus une option : le trafic mobile impose que le contenu s’adapte à l’écran qui l’affiche, et c’est compris dans toutes nos prestations.

Vous ou nous, au choix. Une fois le site créé, il reste les mises à jour courantes : nous pouvons nous en charger, ou vous former pour que vous le fassiez. Ce point se décide au démarrage, parce qu’il change la façon dont le site est construit.

Un site mono-page démarre à 250 € HT. Au-delà, cela dépend du nombre de pages, des fonctionnalités et de la part de sur-mesure — d’où le devis. Il existe aussi une formule de location à 9 € HT par mois, engagement de 12 mois, nom de domaine en sus, qui comprend le site, son hébergement et le support.

Pour beaucoup d’activités, oui. Il répond aux trois questions qu’on se pose : qui êtes-vous, que faites-vous, où vous trouve-t-on. Et comme il est bâti sur un CMS, il reste évolutif : on y ajoute plus tard un blog ou une boutique sans repartir de zéro.

Oui, c’est le principe même du gestionnaire de contenu que nous installons. Nous vous montrons comment vous en servir à la livraison. Si vous préférez ne pas y toucher, nous pouvons nous en charger — mais ce doit être un choix, pas une contrainte technique.

Vous partez avec votre site. Nous construisons sur des logiciels libres précisément pour cela : le code, le contenu et l’hébergement sont dissociables, et n’importe quelle autre agence saura reprendre un WordPress ou un Prestashop.

Nous ne les évitons pas par principe, mais chaque extension ajoutée est du code que personne chez vous ne relit, qui doit être mis à jour, et dont la disparition devient un jour votre problème. Un thème capable facilite la maintenance, n’alourdit pas le site de fonctions inutiles, et vous permet de changer de thème sans tout redévelopper.

Oui, c’est le rôle d’ACF dans nos thèmes : chaque type de page sert de modèle que vous dupliquez à volonté, dans une interface d’édition claire. Vous n’avez pas à toucher au code pour ajouter une page ou un élément.

Le plus souvent oui, et rarement en changeant de serveur. Nous mettons en place des mécanismes de cache, redéveloppons les parties en cause et optimisons le code source ainsi que le HTML, le CSS et le JavaScript. C’est aussi ce qui joue sur le référencement : une page lente perd ses visiteurs avant de s’afficher.

Optimisation de site internet →

Si votre banque est le CIC ou le Crédit Mutuel, nous vous fournissons gracieusement notre extension Monetico, développée en interne. Sinon, nous utilisons le module fourni par votre banque — et s’il n’existe pas, nous le développons.

Boutique en ligne →

Oui, y compris quand elle n’est pas sous WooCommerce : nous écrivons les programmes qui vont chercher les produits et les réintègrent. C’est une pratique courante, pas une exception — et c’est souvent le poste qui pèse le plus dans un devis de migration.

Sur devis : cela dépend entièrement de ce qu’il y a à développer et de l’état de l’existant. Un audit rapide du site permet de dire ce qui relève du réglage et ce qui demande du développement — les deux ne se chiffrent pas de la même façon.

C’est le risque principal d’une refonte, et il se traite en amont. Les adresses des pages existantes sont conservées quand c’est possible, redirigées une à une quand ça ne l’est pas. Un site refait qui perd ses positions a coûté bien plus que son devis.

Référencement →

Presque toujours. S’il existe un export, nous partons de là. S’il n’y en a pas ou qu’il est incomplet, nous écrivons un programme qui va chercher le contenu directement. C’est une pratique courante, pas une exception.

Non. Parfois l’outil est bon et c’est le site qui a mal vieilli : on reprend alors le thème et les réglages sans migrer. Le changement de CMS se justifie quand l’outil actuel bloque — parce qu’il n’est plus maintenu, ou parce qu’il vous empêche de modifier votre propre contenu.

Non. Votre nom de domaine reste chez votre registraire actuel et à votre nom : une refonte ne l’oblige pas à changer de mains. Il en va de même pour l’hébergement : le nouveau site est installé sur votre hébergement actuel, et votre nom de domaine continue d’y mener sans la moindre modification.

Nom de domaine →

Non. Vous restez libre de choisir votre hébergeur et votre formule d’hébergement, et d’en changer ensuite. Le site refait est écrit en code standard, sans dépendance à notre infrastructure : il fonctionne chez tous les hébergeurs. Le nôtre reste une option, pas une condition ; mais héberger ailleurs fait perdre tous ses avantages — sauvegarde quotidienne, pare-feu applicatif, astreinte et garantie de rétablissement en 4 heures.

Notre cloud nantais →

À partir de 250 € HT pour un site simple. Au-delà, tout dépend du volume de contenu à reprendre et de la difficulté à l’extraire — c’est ce poste-là, bien plus que le graphisme, qui fait varier le devis.

C’est le réflexe courant, et c’est le maillon le plus faible : une extension de sécurité tourne à l’intérieur du site qu’elle protège, avec les mêmes droits et les mêmes failles. Nos protections sont en amont, sur la plateforme. Elles restent debout même si le site tombe.

Vous l’êtes contre ce que le correctif corrige, à partir du moment où vous l’appliquez. Le problème est l’intervalle : une faille publiée est exploitée dans les heures qui suivent, pas au rythme de vos mises à jour. C’est exactement ce que couvre la correction virtuelle du pare-feu applicatif.

Rarement en le regardant : un site compromis continue le plus souvent de fonctionner normalement, parce que l’intérêt de l’attaquant est justement qu’on ne s’en aperçoive pas. C’est pourquoi la détection porte sur les fichiers — Imunify repère ceux qui ont été modifiés à votre insu, StopTheHacker contrôle l’intégrité du site.

C’est le premier symptôme visible d’un site compromis, et il arrive presque toujours à l’insu du propriétaire — qui découvre le problème quand son domaine est mis en liste noire. Notre extension weobia_mailhook trace les e-mails envoyés site par site et script par script : nous savons lequel et par quel fichier, au lieu de suspendre le compte entier le temps de comprendre.

Hébergement mutualisé Linux →

Les protections tiennent l’attaque connue, mais une version abandonnée par son éditeur ne recevra plus aucun correctif : le trou s’élargit chaque mois. La seule réponse durable est d’en sortir, et une refonte est généralement le bon moment — c’est même souvent la raison de l’opération.

Refonte de site →

Vous, depuis le WordPress Toolkit de Plesk, qui gère les mises à jour du cœur et des extensions depuis l’interface. Si vous préférez ne pas vous en occuper, c’est une prestation d’accompagnement à part.

Hébergement WordPress →

Non, et c’est la limite à connaître avant de choisir cette voie : le référencement d’une application de ce type est très complexe, souvent impossible. Elle convient à ce qui n’a pas besoin d’être indexé — espace client, tunnel de vente, formulaire. Si vos pages doivent être trouvées sur un moteur, il faut les construire avant qu’elles n’arrivent au visiteur.

Développement Astro →

Ces deux-là savent construire la page côté serveur avant de l’envoyer, ce qui les rend indexables tout en gardant React ou Vue. Une application front classique construit tout dans le navigateur : c’est plus simple à écrire, mais cela ferme la porte au référencement. Le choix se fait donc sur ce point avant tout autre.

Développement Next.js →

C’est plus simple, mais ce n’est pas obligatoire : l’application peut s’appuyer sur des API existantes, et nous pouvons aussi les construire — en Symfony, Python, Java, Go ou Node.js selon ce que le traitement demande.

Développement d’applications métier →

La question à se poser n’est pas laquelle est la meilleure, mais laquelle ceux qui reprendront le projet savent lire. Une équipe déjà formée à l’une des trois, ou un existant à réutiliser, pèsent plus que les mérites comparés des bibliothèques.

Oui, sur la partie affichage : vos serveurs ne manipulent plus que des données et n’envoient plus de HTML, comme le font les applications classiques et les CMS. Ce sont les ressources du navigateur qui travaillent, où l’application est chargée directement.

Quand il existe et qu’il correspond, oui — il sera moins cher et mieux maintenu, et nous vous le dirons. Le sur-mesure se justifie quand votre particularité est précisément ce qui fait votre métier, et que l’outil du marché vous demanderait d’y renoncer pour rentrer dans ses cases.

Celle qui correspond au besoin : Symfony si PHP est déjà en place, Python avec FastAPI pour les API et l’asynchrone, Java ou Kotlin quand la charge et la fiabilité priment, Go pour un service réseau dédié, Node.js pour beaucoup de requêtes simultanées. Nous justifions le choix, et il se discute.

Nos outils et technologies →

Sur devis, après avoir regardé le processus à outiller. Nous cherchons systématiquement à réduire la première version au périmètre qui rend déjà service : une application utile après trois mois vaut mieux qu’un projet complet après deux ans, et elle permet de s’arrêter si le reste ne se justifie plus.

Oui, le code comme les données. L’application est hébergée sur notre infrastructure en France, ce qui nous permet de la dimensionner et de l’exploiter, mais rien ne vous y attache techniquement.

Quand le métier le justifie, oui — et pas ailleurs. Le travers le plus répandu de ceux qui pratiquent ces approches est de les appliquer partout : on obtient trois fois plus de code pour le même résultat, et une équipe qui ne sait plus où corriger un libellé. Nous commençons simple et introduisons ces outils là où la complexité l’exige, souvent sur un seul domaine de l’application.

Non. L’ORM reste, mais il descend d’un étage : il sert à écrire l’implémentation, pas à structurer le métier. Le domaine, lui, ne connaît qu’une interface qui parle sa langue — « les dossiers en attente de validation » plutôt qu’une jointure sur trois tables. C’est ce qui permet de tester les règles sans base de données, et de changer de stockage sans réécrire le métier.

En cessant de faire circuler des chaînes de caractères nues. Une adresse e-mail, un IBAN, un SIRET ou un montant sont représentés par des types dédiés qui portent leur propre règle de validité : l’objet ne peut pas exister s’il est invalide. La validation se fait une fois, là où la donnée entre dans le système, au lieu d’être répétée dans chaque fonction — c’est celle qui oublie qui fait le trou.

Oui, et écrits test-d’abord sur la logique métier — ce qui n’est pas la même chose que d’ajouter des tests après coup pour atteindre un pourcentage. Nous ne visons pas une couverture totale : couvrir 100 % d’un code trivial ne prouve rien. Ce qui compte est que vos règles métier soient couvertes, parce que ce sont elles qu’il faudra modifier dans deux ans.

À la faire évoluer. À la livraison, une application testée et une application non testée se ressemblent — la seconde a même coûté moins cher. La différence apparaît au dix-huitième mois, quand il faut modifier une règle écrite par quelqu’un qui est parti : avec des tests on change et on sait ce qu’on a cassé, sans on n’ose plus toucher. C’est aussi ce qui rend possible une montée de version majeure du framework.

C’est la bonne question, et elle doit être posée avant de choisir l’approche. Un journal d’événements conçu pour n’être jamais modifié se concilie mal avec le droit à l’effacement. Cela se traite — en chiffrant les données personnelles par personne et en détruisant la clé, notamment — mais c’est un sujet à instruire en amont, pas au moment où une demande de suppression arrive.

Accompagnement RGPD →

Trois choses vérifiables. Le code emploie vos mots plutôt que ceux d’un développeur, donc il se relit avec vous. Les règles métier se testent sans base ni serveur, donc elles sont réellement testées. Et changer de base de données ou de version de framework ne demande pas de réécrire le métier. Ce sont des propriétés qui se constatent au bout de deux ans, pas au moment de la livraison.

Cela s’étudie, et la réponse dépend d’un point : est-elle documentée et redéployable ? Une application dont personne ne sait reconstruire l’environnement se reprend, mais la première étape est de retrouver comment elle tourne — ce qui relève d’un travail d’architecture avant tout développement.

Architecture du SI →

Son nom est moins connu que d’autres, mais Porsche, NordVPN et The Guardian l’utilisent — et ce site aussi, ce qui est la démonstration la plus vérifiable que nous puissions donner. Vous pouvez en juger sur pièces : sa vitesse d’affichage est le premier argument de la technologie.

Oui, à condition de le prévoir : le contenu peut venir d’un WordPress ou d’un CMS headless, dont vos équipes gardent l’interface d’administration. C’est le point à trancher au début du projet, parce qu’il détermine la chaîne de publication.

Headless CMS →

Astro quand le site est d’abord fait de pages : vitrine, catalogue, blog, documentation. Next.js quand il s’agit d’une application riche, avec des écrans personnalisés par utilisateur et une logique importante côté navigateur. La question à se poser n’est pas laquelle des deux, mais si votre projet est un site ou une application.

Développement Next.js →

Non, plutôt l’inverse : un site généré en statique ne consomme ni processeur ni mémoire à la visite, donc il tient sur une offre modeste et encaisse des pics qui feraient plier un site classique. Nos offres mutualisées y suffisent largement.

Hébergement mutualisé →

Les îlots permettent d’ajouter de l’interactivité progressivement, sans tout reprendre. Mais si la part applicative devient majoritaire, mieux vaut le reconnaître et changer d’outil que de forcer Astro à faire ce pour quoi il n’est pas fait — nous vous le dirons franchement.

Cela dépend d’une seule chose : est-ce que votre façon de travailler est ce qui vous distingue, ou est-ce qu’elle ressemble à celle des entreprises de votre taille ? Dans le second cas, un outil existant bien paramétré fait le travail pour beaucoup moins cher. Dans le premier, le plier au progiciel revient à renoncer à ce qui vous fait gagner. Nous posons cette question avant le devis.

Parce que c’est un logiciel libre : pas de licence par utilisateur qui augmente à chaque embauche, et aucune décision d’éditeur qui vous impose demain une migration ou un nouveau tarif. Il réunit l’ERP et le CRM dans le même outil, et il est modulaire — on n’active que ce qui sert. Si votre contexte impose autre chose, nous le regarderons avec vous.

Oui, et c’est précisément pour cela que nous développons des modules plutôt que de modifier le cœur du logiciel. Une adaptation faite directement dans le code d’origine est écrasée à la mise à jour suivante — c’est ainsi qu’on se retrouve figé pendant des années sur une vieille version, avec les failles que cela suppose.

Elles sont reprises, et c’est le premier sujet que nous traitons, pas le dernier. Nous regardons ce qui doit être repris, ce qui doit être archivé sans l’être, et ce qui doit être nettoyé avant. Quand il n’existe pas d’export exploitable, nous écrivons le programme qui va chercher les données directement.

Oui, et c’est souvent ce qui donne sa valeur au projet : les commandes remontent, les stocks descendent, le client suit son dossier depuis un extranet. La règle que nous appliquons est qu’une donnée fait foi à un seul endroit et que les autres systèmes la lisent — c’est ce qui évite les trois fichiers clients qui divergent.

Développement Extranet →

Non. Nos équipes, nos bureaux et nos machines sont à Nantes, mais nos clients sont dans toute la France : un projet d’ERP se mène en visioconférence, par partage d’écran et avec un environnement de recette accessible en ligne. Les seuls moments où la présence physique aide vraiment — comprendre le métier, voir les gens travailler — se traitent en une ou deux journées sur site, où que vous soyez.

Nous, sur notre infrastructure nantaise, avec sauvegarde quotidienne et supervision. Un ERP n’est pas un site vitrine : son indisponibilité arrête la facturation, ce qui change les exigences d’exploitation.

Hébergement ERP / CRM →

La frontière. Un intranet s’adresse à vos collaborateurs et reste à l’intérieur de l’organisation ; un extranet s’ouvre à des tiers — clients, partenaires, revendeurs — depuis internet. Les fonctions se ressemblent, les exigences de cloisonnement et de sécurité, non.

Développement Intranet →

C’est plus simple, mais ce n’est pas indispensable : beaucoup de logiciels de gestion savent au moins exporter, et un échange de fichiers programmé suffit à alimenter un extranet. C’est le premier point que nous regardons, parce qu’il détermine une bonne partie du projet.

Développement CRM / ERP →

Sur devis, et le prix dépend surtout de deux choses : la grille des droits et le nombre de systèmes à interconnecter. Le nombre d’utilisateurs, lui, ne change presque rien. Décrivez-nous qui doit voir quoi, et depuis quels outils viennent les données.

C’est ce que nous recommandons : une première version limitée à l’usage qui vous coûte le plus d’heures aujourd’hui — le suivi de commandes, le plus souvent — mise en service vite, puis élargie. Cela permet aussi de vérifier que vos clients s’en servent avant d’investir davantage.

Non. L’extranet est une application web : un navigateur suffit, sur ordinateur comme sur téléphone. C’est aussi ce qui vous évite de gérer un parc d’installations chez des tiers sur lesquels vous n’avez pas la main.

Non, c’est même l’inverse : Gatsby se branche dessus et en récupère la gestion de contenu et l’interface d’administration. Ceux qui écrivent gardent leur outil ; c’est le site public qui change de nature.

Headless CMS →

Astro est notre réponse la plus fréquente sur un site de contenu : il envoie encore moins de code et accepte des composants React, Svelte, Vue.js ou Alpine.js. Gatsby garde l’avantage quand votre équipe est déjà sur React, ou qu’un existant React doit être réutilisé.

Développement Astro →

Pas avec Gatsby, qui produit des pages identiques pour tous — c’est le principe même de la génération statique. Dès que l’écran dépend de l’utilisateur connecté, c’est vers Next.js qu’il faut regarder, qui sait construire la page à la demande.

Développement Next.js →

Pas instantanément : les pages étant générées à l’avance, une publication doit être régénérée. La régénération ciblée des pages concernées ramène le délai à quelques instants, mais c’est un point à régler au début du projet.

Sur notre infrastructure nantaise. Comme le site est statique, il n’a besoin d’aucune machine dédiée : nos offres mutualisées à ressources dédiées y suffisent largement, à partir de 72 € HT par an.

Hébergement mutualisé Linux →

Rarement, et nous vous le dirons. Go n’a pas la richesse d’écosystème de PHP ou de Java pour construire écrans, formulaires et administration : Symfony ou Spring Boot vous coûteront moins cher sur ce terrain. Go se justifie pour ce qui doit encaisser, pas pour ce qui doit être riche.

Développement Symfony →

Node.js quand le sujet est le nombre de connexions en attente et que le traitement est léger, ou quand un seul langage du serveur au navigateur a de la valeur. Go quand il y a du travail réel à faire à chaque requête, et que les ressources comptent.

Développement Node.js →

C’est même l’usage le plus fréquent et le plus rentable : extraire d’une application existante le morceau qui la ralentit, et le remplacer par un service Go dédié. Le reste ne bouge pas, et le gain est mesurable immédiatement.

Très simplement, et c’est l’un de ses arguments : un binaire autonome, sans environnement à reconstituer, sur un serveur privé ou un conteneur. L’empreinte mémoire réduite permet souvent de faire tenir plusieurs services sur la même machine.

Hébergement Go →

Le public et la frontière. L’intranet s’adresse à vos collaborateurs et reste interne ; l’extranet s’ouvre à des tiers depuis internet — clients, partenaires, revendeurs. Les briques se ressemblent, mais un service ouvert sur internet demande un cloisonnement et des protections d’un autre ordre.

Développement Extranet →

Souvent oui, parce qu’ils ne servent pas la même chose : l’ERP porte la gestion, l’intranet donne à chacun ce qui le concerne sans lui ouvrir tout le logiciel ni lui en apprendre les écrans. L’intranet lit alors les données de l’ERP au lieu d’en garder une copie qui deviendrait fausse. Si votre besoin est en réalité de mieux exploiter l’ERP lui-même, nous vous le dirons.

Développement CRM / ERP →

Non, c’est même la première chose à éviter : l’identifiant supplémentaire est le principal frein à l’adoption. L’intranet se branche sur votre annuaire — Active Directory ou OpenLDAP — pour que chacun se connecte avec le compte qu’il utilise déjà.

Par un seul usage, celui qui coûte le plus d’heures ou qui génère le plus d’allers-retours. Un intranet qui fait bien une chose est utilisé ; un portail complet livré d’un coup ne l’est presque jamais. Les fonctions suivantes s’ajoutent une fois la première adoptée.

Ce n’est pas nécessaire, et c’est rarement souhaitable : une machine dans un placard n’est ni sauvegardée, ni supervisée, ni redondée. Nous l’hébergeons sur notre infrastructure en France, avec l’accès restreint à votre réseau ou à vos utilisateurs authentifiés selon ce que vous préférez.

Serveurs privés →

Sur devis. Le prix tient surtout au nombre de circuits à modéliser et aux logiciels à interconnecter — pas au nombre d’utilisateurs. Décrivez-nous le premier usage à outiller et les outils dont il doit tirer ses données.

Les deux font le travail. Symfony est le plus répandu en entreprise en France et c’est celui que nous employons le plus souvent ; Laravel démarre plus vite et couvre davantage de besoins d’emblée. Le critère qui devrait trancher est ce que pratique l’équipe qui reprendra le projet — si vos développeurs sont sur Laravel, le débat est clos.

Développement Symfony →

Pas nécessairement. Une application Laravel classique tourne sur notre mutualisé à ressources dédiées. En revanche, dès qu’elle s’appuie réellement sur des files d’attente et des ouvriers qui tournent en permanence, un serveur privé devient plus adapté.

Hébergement Laravel →

Non. Une partie de l’écosystème Laravel est commerciale — gestion de serveurs, hébergement sans serveur, interface d’administration clé en main — et ce sont de bons produits, mais ils ne sont pas nécessaires. Nous n’en employons aucun : l’exploitation se fait sur notre infrastructure, avec les outils qui servent déjà nos autres hébergements. Une dépendance de moins, et une facture de moins.

Laravel publie une version majeure par an, avec une fenêtre de correctifs plus courte que certains frameworks d’entreprise. Il faut donc prévoir les montées de version plutôt que les subir : une application laissée trois ans sans mise à jour devient coûteuse à rattraper, et expose des failles connues entre-temps. Nous posons ce point au devis.

Sécurisation de site web →

Cela s’étudie, et le critère est le même que pour tout existant : est-elle documentée et redéployable ? Une application dont personne ne sait reconstruire l’environnement se reprend, mais il faut d’abord retrouver comment elle tourne — un travail d’architecture, avant tout développement.

Architecture du SI →

Sur devis, après avoir regardé le processus à outiller. Comme sur nos autres projets, nous cherchons à réduire la première version au périmètre qui rend déjà service — cela permet aussi de s’arrêter si la suite ne se justifie plus.

Développement d’applications →

Spring Boot quand l’écosystème compte : beaucoup d’intégrations tierces, Hibernate, sources de données multiples — vous écrirez moins de code. Micronaut quand vous multipliez les services, que les ressources comptent, ou que la compilation native est un objectif. Nous employons les deux, et nous disons lequel convient avant le devis.

Développement Spring Boot →

Le moment où les erreurs apparaissent. Un composant mal déclaré empêche de compiler, au lieu de faire tomber l’application au démarrage. Sur un projet qui se déploie souvent, cela déplace une catégorie entière d’incidents de la production vers le poste du développeur.

Non, Java fonctionne parfaitement et les deux langages cohabitent dans le même projet. À choix ouvert, Kotlin apporte les coroutines — utiles quand beaucoup de traitements doivent avancer en parallèle — et une syntaxe plus concise. Le critère décisif reste ce que pratique l’équipe qui reprendra le code.

Oui, sensiblement : démarrage immédiat et empreinte mémoire réduite, ce qui permet une machine plus modeste ou plusieurs services sur la même. C’est le principal argument économique du framework, et il est encore plus net en conteneur.

Hébergement Micronaut →

Alors ni Micronaut ni Spring Boot ne sont le meilleur rapport, et nous vous le dirons : une application avec ses écrans, ses formulaires et son administration coûtera moins cher en PHP avec Symfony, à développer comme à héberger.

Développement Symfony →

Astro quand le projet est d’abord fait de pages — vitrine, catalogue, blog, documentation : il envoie beaucoup moins de code pour le même résultat. Next.js quand il s’agit d’une application, avec des écrans personnalisés et une logique importante côté navigateur. La vraie question n’est pas laquelle des deux, mais si votre projet est un site ou une application.

Développement Astro →

Gatsby génère des pages statiques et se branche facilement sur WordPress : c’est le bon choix pour un site de contenu qui doit rester rapide. Next.js sait en plus construire la page à la demande, ce qui devient nécessaire dès que l’écran dépend de l’utilisateur connecté.

Développement Gatsby →

C’est la question à se poser avant de choisir, et elle pèse plus que les mérites techniques. Le meilleur outil est celui que ceux qui reprendront le projet savent lire. Si personne chez vous ne pratique React et qu’aucun existant ne l’impose, nous vous orienterons probablement ailleurs.

Non. Next.js est un logiciel libre et nous l’hébergeons sur notre propre infrastructure, en France. Cela suppose de remplacer explicitement quelques mécanismes fournis par sa plateforme d’origine — le cache des images, la régénération des pages, le cache partagé — ce que nous faisons à la mise en service.

Hébergement Next.js →

Oui, à condition de générer les pages à l’avance ou de les rendre côté serveur — ce que Next.js sait faire. C’est un choix d’architecture posé au début : une application qui construit tout dans le navigateur reste très difficile à indexer, souvent impossible.

Référencement / SEO →

PHP quand l’application répond à des requêtes ordinaires et que le coût d’hébergement compte : elle tourne alors sur un mutualisé, sans machine à administrer. Node.js quand le nombre de connexions simultanées est le sujet, ou quand vouloir un seul langage du serveur au navigateur a de la valeur pour votre équipe.

Développement Symfony →

Oui, ou un conteneur : une application Node.js est un programme qui tourne en permanence, pas un script appelé à chaque visite. C’est le principal écart de coût avec PHP, et nous le disons avant le devis.

Hébergement Node.js →

Moins bien. Son avantage tient à la gestion de l’attente, pas à la puissance de calcul : un traitement long et continu occupe le processus et bloque le reste. Pour ce type de charge, Java, Kotlin ou Go sont mieux placés — et nous vous le dirons.

Développement Spring Boot →

Sur tout ce qui doit durer, oui. Le typage rend le code lisible par quelqu’un qui ne l’a pas écrit, et c’est la première qualité d’une application qu’une autre équipe reprendra dans deux ans.

Les deux font le même travail, l’un sur Vue, l’autre sur React. Le choix se joue sur ce que pratique l’équipe qui reprendra le projet, et Vue passe souvent pour plus accessible à une équipe non spécialisée en front. Techniquement, aucun des deux ne vous bloquera.

Développement Next.js →

Astro, presque toujours : il fait le même travail en envoyant beaucoup moins de code, et il sait employer des composants Vue.js là où de l’interactivité est utile. Nuxt prend l’avantage quand la part applicative devient importante, ou quand toute votre équipe est déjà sur Vue.

Développement Astro →

C’est la question à poser en premier, avant tout le reste. Statique si le contenu peut être connu à l’avance — l’hébergement est alors trivial et bon marché. Rendu serveur si l’écran dépend de l’utilisateur connecté, ce qui suppose une machine et un autre ordre de coût. Beaucoup de projets choisissent le second sans en avoir besoin.

Hébergement Nuxt →

Oui, à condition de générer les pages à l’avance ou de les rendre côté serveur. C’est ce qui distingue Nuxt d’une application front qui construit tout dans le navigateur, dont le référencement est très complexe, souvent impossible.

Référencement / SEO →

Une API, c’est FastAPI. Une application avec ses écrans, ses formulaires et son administration, c’est Django. Le choix se fait sur ce que vous construisez, et il se tranche généralement en une phrase.

Pour une API, oui : FastAPI atteint des performances proches de Node.js et de Go grâce à son architecture asynchrone. La réserve porte sur le calcul intensif et continu, où un langage compilé garde l’avantage — Go ou Java selon le cas.

Développement Go →

Oui, ou un conteneur. Comme une application Node.js, une application Python tourne en permanence et ne peut pas vivre sur une plateforme mutualisée. C’est un écart de coût par rapport à PHP, et il vaut mieux le connaître avant de choisir.

Hébergement Python →

Cela s’étudie. La question première n’est pas le langage mais la reproductibilité : sait-on reconstruire l’environnement et redéployer l’application ? Si non, c’est par là qu’il faut commencer, et cela relève d’un travail d’architecture.

Architecture du SI →

React seul quand l’interface s’insère dans une application qui existe déjà et qui garde ses URL. Next.js quand le projet EST le site : il ajoute le routage et le rendu côté serveur, donc l’indexation. La question à poser d’abord est celle-là — construisez-vous un écran, ou un site ?

Développement Next.js →

Techniquement, les deux font le même travail et le choix se joue ailleurs. React a le vivier le plus large ; Vue s’adopte plus progressivement, page par page, sans réécrire l’existant. Si vos équipes en pratiquent une, c’est celle-là.

Développement Vue.js →

Non, s’il est construit dans le navigateur : c’est très complexe à indexer, souvent impossible. Pour un espace connecté, cela n’a aucune importance. Pour une page publique, il faut un rendu côté serveur, et l’outil s’appelle alors Next.js.

Référencement / SEO →

Non, et c’est l’intérêt principal de cette approche. React s’installe sur un seul écran, branché sur vos API existantes. Le reste de l’application continue de tourner comme avant, et la décision reste réversible.

C’est la question à se poser avant de choisir, et elle pèse plus que les mérites techniques. Le meilleur outil est celui que ceux qui reprendront le projet savent lire. Nous documentons le code et nous le remettons ; s’il doit vivre chez vous, autant qu’il soit écrit dans ce que vous pratiquez.

Les deux cohabitent dans le même projet, et le critère décisif est ce que pratique l’équipe qui reprendra le code. À choix ouvert, Kotlin apporte les coroutines — utiles quand beaucoup de traitements doivent avancer en parallèle — et une syntaxe qui évite d’écrire du code superflu.

Node.js quand le sujet est le nombre de connexions simultanées et que le traitement est léger. Spring Boot quand le sujet est la fiabilité, le volume de données ou l’intégration avec plusieurs bases existantes. Les deux font des API ; ils ne résistent pas aux mêmes contraintes.

Développement Node.js →

Oui, et il faut le dire avant le devis : une application Spring Boot demande une machine à elle et plus de mémoire qu’une application PHP. La compilation native via GraalVM réduit nettement cet écart quand elle est possible.

Hébergement Spring Boot →

Cela s’étudie, et la question première n’est pas le langage : est-elle documentée et redéployable ? Retrouver comment une application tourne relève d’un travail d’architecture, à mener avant tout développement.

Architecture du SI →

Svelte seul pour un composant posé dans des pages qui existent. SvelteKit dès que le projet est un site : il apporte le routage et le rendu côté serveur, donc l’indexation. Le partage est le même qu’entre React et Next.js.

Développement SvelteKit →

Pour une seule raison qui tienne : le poids envoyé au navigateur. Svelte ne lui livre pas de moteur d’interface, seulement votre écran compilé. Si le premier affichage et la légèreté sont des contraintes réelles de votre projet, l’écart se mesure. Sinon, le vivier plus large de React ou de Vue pèse davantage.

Développement React →

Moins facilement qu’en React ou en Vue, et il faut le savoir avant de choisir. C’est la contrepartie de cet outil. Si le code doit vivre chez vous et que personne ne le pratique, nous vous orienterons probablement ailleurs — c’est un conseil, pas une réticence.

Pas s’il est construit dans le navigateur : comme toute interface de ce type, l’indexation est très complexe, souvent impossible. Pour des pages publiques, il faut un rendu côté serveur — c’est le rôle de SvelteKit.

Référencement / SEO →

Oui, un composant Svelte s’installe dans une page servie par votre outil actuel, comme le ferait un composant Vue. C’est même le cas où son poids réduit se remarque le plus, puisqu’il s’ajoute à un existant que vous ne maîtrisez pas forcément.

Les deux résolvent le même problème et se ressemblent beaucoup dans l’usage. Next.js a le vivier de développeurs le plus large, ce qui compte pour la reprise. SvelteKit envoie moins de code au navigateur. Si vous n’avez pas de contrainte de poids et pas d’équipe Svelte, Next.js reste le choix le plus sûr — nous le disons volontiers.

Développement Next.js →

Astro quand le projet est d’abord fait de pages — vitrine, catalogue, blog, documentation. SvelteKit quand il s’agit d’une application, avec des écrans personnalisés et une logique importante. La vraie question n’est pas laquelle des deux, mais si votre projet est un site ou une application.

Développement Astro →

Oui, à condition de générer les pages à l’avance ou de les rendre côté serveur — ce que SvelteKit sait faire. C’est un choix d’architecture posé au début : une application qui construit tout dans le navigateur reste très difficile à indexer, souvent impossible.

Référencement / SEO →

Non. SvelteKit est un logiciel libre et nous l’hébergeons sur notre propre infrastructure, en France. L’exécution demande un environnement JavaScript côté serveur, que nous exploitons déjà pour d’autres frameworks du même type.

Développement Node.js →

Moins facilement qu’en React ou en Vue. C’est la contrepartie honnête de cet écosystème, et elle doit peser dans la décision au même titre que les mérites techniques. Si le code doit vivre chez vous et que personne ne pratique Svelte, nous vous orienterons ailleurs.

Pour deux raisons concrètes. L’hébergement d’abord : une application PHP tourne sur une plateforme mutualisée à ressources dédiées, sans machine à administrer, là où Java ou Node demandent un serveur dédié — l’écart de coût mensuel court pendant des années. Les gens ensuite : PHP est le langage le plus répandu du web, donc le plus facile à faire reprendre.

Les deux sont des frameworks PHP solides et les projets se ressemblent davantage qu’on ne le dit. Symfony est le plus répandu en entreprise en France, avec des composants réutilisables et une gouvernance stable — c’est celui que nous employons. Si votre équipe pratique déjà Laravel, c’est un argument sérieux en sa faveur : le meilleur outil reste celui que ceux qui reprendront le projet savent lire.

Développement Laravel →

Sur notre infrastructure, en France. Une application Symfony a des besoins précis — version de PHP, cache, tâches planifiées, écriture disque — que nos offres couvrent sans machine dédiée dans la plupart des cas. Le détail de l’exécution figure sur la page d’hébergement dédiée.

Hébergement Symfony →

Sur devis, après avoir regardé le processus à outiller. Nous cherchons systématiquement à réduire la première version au périmètre qui rend déjà service : une application utile après trois mois vaut mieux qu’un projet complet après deux ans.

Développement d’applications →

Cela s’étudie, et le critère décisif est simple : est-elle documentée et redéployable ? Une application dont personne ne sait reconstruire l’environnement se reprend, mais la première étape consiste à retrouver comment elle tourne — ce qui relève d’un travail d’architecture avant tout développement.

Architecture du SI →

Vue seul quand l’interface s’ajoute à des pages qui existent et qui gardent leurs URL. Nuxt quand le projet EST le site : il apporte le routage et le rendu côté serveur, donc l’indexation. La question à trancher d’abord est celle-là — ajoutez-vous un composant, ou construisez-vous un site ?

Développement Nuxt →

Techniquement, les deux font le même travail. React a le vivier de développeurs le plus large ; Vue s’ajoute plus facilement à un existant, sans réécriture préalable. Si vos équipes en pratiquent une, prenez celle-là — c’est le critère qui compte le plus au moment de reprendre le code.

Développement React →

Non, c’est précisément son intérêt. Un composant s’installe dans une page servie par votre outil actuel, et rien d’autre ne bouge. Ce site en est l’exemple : un seul îlot Vue, chargé quand il devient visible, sur des pages autrement dépourvues de JavaScript.

Seulement celles qui en contiennent, et seulement quand le composant devient visible si on le configure ainsi. Une page sans composant n’envoie rien de plus qu’avant. C’est l’inverse d’une application front, qui charge son moteur sur toutes les pages.

La documentation de Vue est réputée abordable, et le passer à une équipe qui n’en fait pas encore demande moins d’effort que ses concurrents. Cela dit, le meilleur outil reste celui que ceux qui reprendront le projet savent déjà lire.

Non, c’est même l’intérêt de l’approche : le back-office reste celui qu’elles connaissent. Ce qui change est la façon dont les pages publiques sont fabriquées — et cela ne se voit pas depuis l’administration.

C’est le point à décider en amont. Les pages étant générées à l’avance, une modification doit se propager : régénération ciblée des fiches concernées, ou lecture du prix et du stock côté navigateur pour ce qui doit être temps réel. Les deux se font ; le choix dépend de la fréquence de vos changements.

Au contraire, et c’est là que la confusion se fait avec les applications front. Une SPA construit ses pages dans le navigateur : son référencement est très complexe, souvent impossible. Un site headless génère les pages avant la visite — elles s’indexent normalement, et leur vitesse joue en leur faveur.

Application front SPA →

Non, et nous le dirons. Sur une petite boutique déjà bien hébergée, le gain est réel mais rarement décisif au regard de la complexité ajoutée. Le headless prend son sens quand l’audience est là, quand la vitesse est un argument commercial, ou quand la vitrine doit vivre indépendamment du back-office.

Oui, c’est un cas fréquent : Gatsby se branche facilement sur WordPress, dont il récupère alors la gestion de contenu et l’interface d’administration. Avec WooCommerce derrière, on obtient une vitrine statique très rapide sur une gestion que vous connaissez déjà.

Développement WordPress →

Magento se justifie sur les gros catalogues et les organisations à plusieurs boutiques, plusieurs langues ou plusieurs grilles tarifaires. Prestashop couvre très bien la boutique unique avec un catalogue de quelques centaines à quelques milliers de références, pour un coût de possession nettement inférieur. Le nombre de boutiques est souvent le critère qui tranche.

E-commerce Prestashop →

Magento est supporté sur nos offres mutualisées, et le module LiteSpeed correspondant y accélère les temps de réponse sans surcoût. Pour une boutique à fort trafic ou un gros catalogue, nous regardons ensemble si le mutualisé suffit ou si un serveur privé est plus adapté — c’est la solution retenue pour la plateforme SVVP.

Serveurs privés →

Oui, y compris sans accès à la base de données de l’ancien site. Nous écrivons alors des programmes qui vont chercher les produits directement sur les pages existantes et les réintègrent. C’est la méthode que nous avons employée pour SVVP, et c’est la partie la plus longue du projet — elle se chiffre à part.

La refonte SVVP →

Sur devis, et le périmètre change tout : reprendre trois boutiques existantes avec récupération de catalogue n’a aucun rapport avec la mise en place d’une vitrine unique. Décrivez-nous votre catalogue et votre organisation, nous chiffrons après — et nous vous dirons si un outil plus léger suffit.

Alors Magento n’est probablement pas pour vous, et nous vous le dirons. Sur quelques dizaines de références et une seule boutique, WooCommerce sur WordPress ou Prestashop coûtent bien moins cher à mettre en place comme à faire vivre.

Développement WordPress →

Question de volume et d’organisation. WooCommerce, greffé sur WordPress, suffit à quelques dizaines de produits sur une boutique unique. Prestashop couvre la boutique structurée de quelques centaines à quelques milliers de références. Magento se justifie sur les gros catalogues et les organisations à plusieurs boutiques ou plusieurs marques.

E-commerce Magento →

Oui, c’est l’objectif : produits, prix, stocks et commandes se tiennent depuis l’administration, sans nous. Nous intervenons sur ce qui sort de l’usage courant — une évolution du thème, un module, une montée de version. La boutique, son contenu et ses photos vous appartiennent.

Le moins possible, et c’est un conseil, pas une économie. Chaque module est du code tiers à maintenir, et il rendra la prochaine montée de version plus difficile. Nous préférons ce que le cœur sait déjà faire, quitte à adapter le thème.

C’est le risque principal, et il se traite en amont. Les adresses des fiches produits sont conservées quand c’est possible, redirigées une à une quand ça ne l’est pas. Sur une boutique, chaque fiche est une page qui peut être positionnée — les perdre en masse se voit immédiatement.

Référencement / SEO →

Sur devis. Le prix dépend beaucoup moins du nombre de produits que de la structure du catalogue, des règles de livraison et de ce qu’il faut récupérer de l’existant. Décrivez-nous ces trois points et nous chiffrons.

Non, et c’est tout l’intérêt : vous continuez d’émettre vos factures depuis l’outil que vous utilisez déjà, avec vos modèles et vos habitudes. Ce qui change est le chemin que prend l’e-mail — il passe par un accès SMTP que nous vous attribuons avant d’arriver à votre client.

Dès qu’un e-mail part de votre logiciel de facturation, nous l’interceptons et en extrayons les données utiles. Une demande de règlement par carte bancaire est créée, puis l’e-mail est transmis à votre destinataire, qui peut payer en ligne.

Non : la plateforme est compatible multi-banques, et prend également en charge PayPal et Stripe. Elle s’adapte à l’établissement avec lequel vous travaillez plutôt que de vous en imposer un.

La facture qu’il attendait, dans le même e-mail, avec la possibilité de régler en ligne. Il dispose en plus d’un espace sécurisé, accessible avec son adresse e-mail, où il retrouve ses factures précédentes — ce qui évite les demandes de duplicata.

À partir de 2 € HT par mois. La plateforme a d’abord été développée pour nos propres besoins avant d’être ouverte à tous : elle est utilisée quotidiennement chez nous, ce qui est la meilleure garantie que nous puissions en donner.

Nous contacter →

Non, et c’est souvent le contraire : WordPress fait très bien le rôle de CMS headless. Il garde la gestion du contenu et son interface d’administration, un autre outil fabrique les pages publiques. Vos équipes ne changent pas d’écran, et vous restez sur un outil que n’importe quel prestataire sait reprendre.

Développement WordPress →

Pas instantanément : les pages étant générées à l’avance, une modification doit être régénérée. C’est le compromis de l’approche, et il se règle en début de projet — régénération ciblée des pages concernées plutôt que du site entier, ce qui ramène le délai à quelques instants.

Sur la partie publique, nettement : elle n’expose ni base de données, ni extensions, ni page de connexion, et n’exécute rien à la demande. Le CMS reste à protéger, mais il peut n’être joignable que depuis vos locaux — ce qui retire l’essentiel de la surface d’attaque.

Sécurisation de site web →

Non. Sur un site de vingt pages mis à jour trois fois par an, la complexité ajoutée ne rapporte rien : un WordPress bien hébergé fait le travail pour moins cher. Le headless prend son sens quand le trafic est là, quand la sécurité est un sujet, ou quand le contenu doit servir ailleurs que sur le site.

Notre réponse la plus fréquente est WordPress en mode headless, parce qu’elle ne demande à personne de réapprendre son outil. Si votre contexte impose autre chose — une équipe déjà formée, un besoin éditorial particulier — parlons-en : c’est un choix qui se discute au cas par cas.

Rarement. La plupart des sites lents le sont pour une cause identifiable qui se corrige sans tout reprendre. La refonte se justifie quand le socle est obsolète ou que l’outil bloque, pas parce que les pages mettent trois secondes à s’afficher.

Refonte de site →

Oui, et directement : une page lente est pénalisée, et elle l’est deux fois puisque les visiteurs partent avant de l’avoir vue. C’est l’un des leviers du référencement naturel, mais ce n’est pas le seul — la structure et les contenus comptent autant.

Référencement / SEO →

Oui, la mesure et une bonne partie des corrections ne dépendent pas de l’hébergeur. Nous vous dirons en revanche honnêtement si la cause principale est la machine : dans ce cas, optimiser le code revient à repeindre une pièce dont le plancher est pourri.

La mesure et le diagnostic sont courts — c’est la partie qui donne la réponse. Les corrections dépendent de ce qu’on trouve : redimensionner des images est l’affaire de quelques heures, revoir des requêtes qui datent de dix ans peut demander plusieurs jours. Nous chiffrons après le diagnostic, pas avant.

La part technique, oui : les sites que nous construisons sont livrés avec les extensions utiles au référencement naturel, et vous n’avez rien à installer pour être correctement indexé. Le travail éditorial, la structure et le suivi des positions relèvent d’une prestation à part, établie sur devis.

Création de site internet →

Sur devis. Le périmètre change beaucoup d’un site à l’autre : reprendre la structure d’un site de dix pages et suivre les positions d’une boutique de plusieurs milliers de références ne demandent pas le même travail. Appelez-nous, nous regardons votre site et nous vous disons ce qu’il y a à faire — et ce qu’il n’y a pas à faire.

Très difficilement. Le référencement d’une application de ce type est complexe, souvent impossible : elle convient à ce qui n’a pas besoin d’être indexé — un espace client, un outil métier. Si le contenu doit être trouvé sur les moteurs, c’est un site qu’il faut, pas une application front.

Application front SPA →

Oui, et pas seulement pour vos visiteurs : un site illisible sur smartphone nuit directement à son référencement naturel. C’est ce qui a motivé la refonte du site de Teddy-Pack. Tous les sites que nous construisons s’adaptent à tous les écrans — ce n’est pas une option, c’est systématique.

Refonte de site →

Par la vitesse, oui. Une page lente est pénalisée, et la vitesse dépend autant du site que de la machine qui le sert. Nos hébergements reposent sur des ressources dédiées et garanties : un site voisin ne peut pas ralentir le vôtre. Avoir le site et l’hébergement au même endroit évite aussi de se renvoyer la balle quand quelque chose est lent.

Hébergement mutualisé →

Non, et personne ne le peut sérieusement : le classement n’appartient à aucun prestataire. Ce sur quoi nous nous engageons est ce qui dépend de nous — un site techniquement propre, une structure qui tient, des contenus écrits pour être lus, et un suivi qui vous dit où vous en êtes.

Sur nos infrastructures à Nantes — à Saint-Herblain notamment — et dans d’autres centres de données en France. Les données qui nous sont confiées sont les vôtres et restent confidentielles, et les seules lois qui s’y appliquent sont françaises et européennes.

Espace disque, processeur et mémoire vous sont attribués : un autre site ne peut pas ralentir le vôtre en consommant ce qui vous revient. Nous n’hébergeons par ailleurs aucun site susceptible de mettre les autres en danger — c’est l’inverse du modèle qui surprovisionne pour tirer les prix vers le bas.

Hébergement mutualisé →

Une astreinte couvre les heures non ouvrées, et nous nous engageons sur un temps de rétablissement de 4 heures. La sauvegarde est quotidienne et conservée 30 jours, et un pare-feu applicatif se tient devant chaque site.

Par le nom de domaine et l’hébergement mutualisé : c’est ce que couvrent la grande majorité des besoins, y compris pour une boutique. Les serveurs privés et dédiés répondent à des contraintes précises — configuration, charge, isolation — et il vaut mieux les prendre quand elles apparaissent, pas avant.

Non. Ce cloud et l’ensemble des prestations qui s’y rattachent sont conçus et maîtrisés par nos équipes. C’est ce qui nous permet de répondre à des besoins très différents, y compris sur mesure — et de savoir exactement ce qui se passe quand quelque chose ne va pas.

À propos de l’agence →

Des boîtes suffisent si chacun gère son courrier de son côté. La messagerie collaborative devient utile dès que les agendas, les contacts ou les tâches doivent être partagés et synchronisés entre tous les appareils — c’est ce qui la distingue, bien plus que la boîte elle-même.

Hébergement d’e-mails →

Les deux répondent au même besoin : une alternative complète à Exchange, avec ActiveSync, agendas, contacts, tâches et notes. Le choix se fait sur les habitudes de vos utilisateurs et sur les modules dont vous vous servirez réellement. Appelez-nous, c’est plus rapide que de lire deux fiches produit.

Kerio Connect →

Non : toutes nos solutions intègrent une protection contre les spams et les virus. Sur les boîtes simples, vous pilotez vous-même le niveau de filtrage depuis un panneau d’administration, listes blanches et noires comprises. Sur les messageries collaboratives, Sophos et Bitdefender sont fournis.

Oui. La passerelle anti-spam se place devant lui et filtre avant que les messages ne l’atteignent, sans rien changer à sa configuration : nous recevons le courrier à sa place et ne lui transmettons que le trafic légitime.

Passerelle anti-spam →

C’est l’usage, et c’est ce que nous mettons en place : les adresses portent votre domaine, que nous pouvons également gérer. Une adresse professionnelle chez un fournisseur grand public dit à vos correspondants que l’entreprise n’a pas son propre nom sur internet.

Nom de domaine →

Oui, et ils ne s’appliquent que la première année. Sur l’offre E-Mail Pro, ils sont de 30 € HT. Sur l’offre NoLimit, ils correspondent à un mois de location. Nous préférons l’écrire ici plutôt que de le découvrir sur la facture.

Autant que vous voulez : comptes, alias, redirections et répondeurs sont illimités sur les deux offres. La facturation porte sur le volume stocké et sauvegardé, pas sur le nombre de boîtes.

Non. Ces offres sont des messageries professionnelles, et l’usage marketing y est prohibé — c’est ce qui permet de préserver la réputation de nos serveurs d’envoi, donc la délivrabilité de tous. Pour des campagnes, c’est une autre infrastructure.

Marketing B2B →

C’est précisément ce que couvre l’offre NoLimit : vous confiez la messagerie, nous prenons en charge les maintenances et l’administration. Le stockage et le trafic sont illimités ; en revanche la sauvegarde n’y est pas incluse et se souscrit à part.

En France, à Nantes ou à Strasbourg, sur du matériel qui nous appartient. Nous ne lisons pas le contenu de vos messages et nous ne l’exploitons à aucune fin. Aucune législation extraterritoriale de type Patriot Act ne s’y applique.

Les deux répondent au même besoin : une alternative complète à Exchange, avec ActiveSync, agendas, contacts, tâches et notes. Le choix se fait sur les habitudes de vos utilisateurs et sur les modules dont vous vous servirez réellement, pas sur une comparaison de fonctionnalités sur le papier. Appelez-nous, c’est plus rapide que de lire deux fiches produit.

Kerio Connect →

Si vous voulez seulement des adresses à votre nom de domaine, non : l’hébergement d’e-mails y répond, et il est facturé au volume conservé plutôt qu’au nombre de boîtes. La suite se justifie dès que les agendas doivent se partager, que les contacts doivent être communs, ou que tout doit se retrouver sur les mobiles.

Hébergement d’e-mails →

Oui. Le filtrage se fait en amont de la boîte, par notre passerelle anti-spam et anti-virus entrante, avant même que le message atteigne la messagerie. C’est plus efficace qu’un filtre appliqué à l’arrivée, et cela vaut pour toutes nos offres de messagerie.

Passerelle anti-spam →

Sur notre infrastructure, à Saint-Herblain et dans d’autres centres de données en France, sur du matériel qui nous appartient. Les seules lois applicables sont françaises et européennes — ce qui n’est pas le cas d’un service opéré par une société soumise à un droit étranger, où que soient ses machines.

Sur les fonctionnalités, très peu : ActiveSync, e-mails, calendriers, contacts, tâches et notes y sont tous. Sur le prix, beaucoup — le mode de fonctionnement de Kerio réduit les coûts de licence, ce qui nous permet de proposer les mêmes fonctionnalités à un tarif deux fois moins élevé, antivirus et antispam compris là où ils sont en supplément ailleurs.

Non. ActiveSync est inclus, et ce n’est pas une option payante : un rendez-vous ajouté sur un poste apparaît sur tous les appareils synchronisés avec le compte — smartphone, tablette, portable ou fixe.

Oui. Tous les clients de messagerie sont supportés, avec des fonctionnalités avancées variables selon celui que vous employez ; la synchronisation complète — e-mails, calendriers, contacts — est prise en charge avec Outlook.

Les comptes sont livrés avec 10 Go, extensibles à 25 ou 50. Quel que soit le volume souscrit, cet espace vous est dédié et garanti : c’est l’inverse du modèle low-cost, qui surprovisionne pour tirer les prix vers le bas. Les données sont par ailleurs stockées trois fois, à trois endroits différents.

Les deux répondent au même besoin : une alternative complète à Exchange, avec ActiveSync, agendas, contacts, tâches et notes. Le choix se fait sur les habitudes de vos utilisateurs et sur les modules dont vous vous servirez réellement, pas sur une comparaison de fonctionnalités sur le papier. Appelez-nous, c’est plus rapide que de lire deux fiches produit.

IceWarp →

Oui, un essai gratuit de 30 jours est possible — demandez-le nous. Il n’y a ensuite aucun engagement minimal : le tarif démarre à 4,50 € HT par compte et par mois, et devient dégressif à partir de 10 comptes, jusqu’à 2,50 € HT.

Nous contacter →

Oui. Si vous exploitez un Active Directory, nous pouvons le synchroniser avec Kerio, ce qui évite de tenir deux listes d’utilisateurs en parallèle. Toutes les fonctionnalités de Kerio Connect sont actives, y compris DKIM, les enregistrements SPF et l’apprentissage de l’antispam.

Non, et c’est tout l’intérêt : la passerelle se place devant ce que vous avez déjà. Votre serveur interne, nos comptes e-mail ou n’importe quel autre fournisseur — Linux, Exchange, Kerio Connect. Seul l’acheminement change, pas vos boîtes ni vos logiciels.

Moins de cinq minutes. Il n’y a rien à installer sur les postes : le filtrage se fait en amont, avant que les messages n’atteignent votre messagerie.

C’est le risque de tout filtrage, et c’est pourquoi aucune couche ne décide seule : les scores sont pondérés entre la validation du serveur émetteur, la liste grise et l’analyse de contenu. Un expéditeur expressément autorisé par les enregistrements SPF de son domaine saute d’ailleurs l’étape de liste grise.

Un message est rejeté à la première présentation puis accepté à la seconde : un serveur légitime réessaie, un faux serveur d’envoi non. Le seul effet visible est un léger délai sur le premier message d’un nouvel expéditeur — et il disparaît si son domaine publie des enregistrements SPF corrects.

Elle est offerte avec tous les noms de domaine que nous gérons et avec tous nos hébergements. Dans les autres cas, le tarif dépend du nombre de boîtes gérées et se donne sur demande. L’assistance technique est incluse et gratuite.

Nous contacter →

Non : la passerelle protège la messagerie, en amont. Pour les postes eux-mêmes — fichiers, navigation, supports amovibles — c’est un antivirus poste qu’il faut, que nous proposons en abonnement.

Antivirus et anti-spam →

Des images : c’est le principe même du conteneur, et c’est ce qui garantit que ce qui tourne en production est ce que vous avez testé. Votre chaîne de construction reste la vôtre. Si vous n’en avez pas encore, c’est un point à traiter avant l’hébergement, pas après.

Hors des conteneurs, et c’est la question à trancher en premier. Base de données, fichiers déposés, sessions : tout ce qui doit survivre à la destruction d’un conteneur est sorti sur des services dédiés — bases répliquées, stockage partagé, cache en mémoire. Un conteneur qui garde son état n’est pas jetable, et perd l’essentiel de son intérêt.

La conteneurisation n’est pas une fin en soi. Une application stable sur un serveur bien tenu n’a pas à changer de forme pour le principe. Le conteneur se justifie quand vous déployez souvent, quand plusieurs environnements doivent être identiques, ou quand plusieurs applications doivent cohabiter sans se marcher dessus.

Serveurs privés →

Oui, c’est le fonctionnement normal : les réplicas d’un service sont remplacés un par un, et le déploiement s’interrompt de lui-même si les nouveaux ne passent pas leur contrôle de santé. Deux conditions côté application : plusieurs réplicas, et un processus qui s’arrête proprement pour ne pas couper une requête en cours.

Un seul suffit à faire tourner des conteneurs, mais il ne survit à rien : si la machine tombe, tout tombe. La bascule automatique suppose au moins un second nœud capable d’accueillir les conteneurs du premier — et donc une capacité laissée libre exprès. C’est un arbitrage de coût, que nous posons dès le dimensionnement.

Haute disponibilité →

Nous exploitons Docker en mode Swarm, qui couvre la majorité des besoins avec beaucoup moins de pièces mobiles. Si votre contexte impose un autre orchestrateur, la question relève de l’étude d’architecture plutôt que d’un hébergement sur catalogue — parlons-en.

Consulting DevOps →

Rarement. C’est l’avantage le plus concret de Go en exploitation : quelques dizaines de méga-octets de mémoire par service, là où d’autres technologies en demandent des centaines. Une machine modeste porte plusieurs services — c’est ainsi que tournent nos propres outils réseau.

Moins qu’ailleurs. Le principal apport d’un conteneur est de figer un environnement, et un binaire Go n’en a pas. Cela reste pertinent si vous déployez très souvent ou si le reste de votre pile est déjà conteneurisé.

Hébergement Docker →

En faisant tourner deux instances derrière le proxy et en les remplaçant l’une après l’autre. Le démarrage d’un binaire Go étant quasi instantané, l’opération est plus simple que sur la plupart des autres technologies.

Haute disponibilité →

Oui, et nous employons Go pour nos propres besoins : redirection HTTP, vérification d’adresses IP en listes noires, détection de botnets, serveurs SMTP entrants et sortants. C’est ce qui nous permet d’en parler autrement que par la documentation.

Développement Go →

Posez-vous cette question : votre application enverrait-elle encore ses e-mails si personne ne consultait le site pendant une heure ? Si oui, vous avez des files d’attente actives, donc des processus permanents, et il vous faut une machine. Sinon, le mutualisé à ressources dédiées fait le travail pour une fraction du prix.

Serveurs privés →

Oui. L’ordonnanceur de Laravel ne demande qu’une seule tâche planifiée, appelée chaque minute, qui décide ensuite quoi exécuter. C’est un besoin banal et il est couvert — inutile de changer de formule pour ça.

Nous, sur serveur privé infogéré : ils sont supervisés et relancés automatiquement s’ils s’arrêtent. C’est le point qu’on découvre tard quand personne ne regarde — une file dont le consommateur est mort continue d’accepter des travaux que plus rien ne traite.

Infogérance →

Oui. Avoir le développement et l’hébergement au même endroit évite de se renvoyer la balle quand quelque chose est lent — et sur une application PHP, la cause est aussi souvent dans le code que sur la machine.

Développement Laravel →

Les besoins sont les mêmes — une machine, un superviseur, un proxy — mais les contraintes qui coûtent cher disparaissent. Une application Spring Boot classique demande des dizaines de secondes pour démarrer et beaucoup de mémoire ; Micronaut fait l’assemblage à la compilation, donc démarre tout de suite et consomme moins. La machine est plus petite et les redémarrages ne font plus peur.

Hébergement Spring Boot →

C’est là que l’écart est le plus net. Le mode d’échec le plus courant d’une application Java en conteneur — l’orchestrateur qui la tue avant qu’elle ait fini de démarrer, puis la relance indéfiniment — n’a plus lieu d’être. Et l’empreinte réduite permet de faire tenir davantage de services sur le même cluster.

Hébergement Docker →

Non, l’essentiel du gain est déjà là sans elle. Elle pousse simplement la logique plus loin : un binaire qui démarre en millisecondes et consomme une fraction de la mémoire, avec un hébergement qui ressemble à celui d’un service Go. Micronaut y a été conçu, là où d’autres frameworks s’en accommodent difficilement.

Hébergement Go →

Non : comme toute application JVM, Micronaut tourne en permanence, alors qu’une plateforme mutualisée exécute un script à l’arrivée d’une requête puis l’oublie. Il lui faut un serveur privé ou un conteneur — mais nettement plus modeste qu’une application Java classique.

Serveurs privés →

Oui. Micronaut fait partie des frameworks que nous employons sur la JVM, aux côtés de Spring, pour obtenir rapidement des applications fiables capables d’absorber la majorité des charges — avec Kotlin ou Java selon ce que pratique l’équipe.

Développement Micronaut →

Un site vitrine tient dans la formule 1 Go. Passez à 2 Go si le site multiplie les bases de données. La formule 10 Go se justifie dès que vous hébergez plusieurs sites — jusqu’à trois — ou que la messagerie prend de la place. L’offre Illimitée est réservée aux sites et applications métier. Dans le doute, appelez-nous.

Le détail des formules →

Oui. Un certificat Let’s Encrypt est inclus et automatique dans toutes nos offres d’hébergement : votre site s’affiche en https avec le cadenas, sans démarche ni surcoût. Il valide le nom de domaine. Dès qu’il y a un paiement ou un compte client, un certificat qui valide en plus votre organisation se justifie.

Certificats SSL →

Linux par défaut : c’est ce que demandent WordPress, Prestashop, Magento et la quasi-totalité des sites. Le Windows se justifie pour un besoin précis — une base SQL Server, une application en ASP. Si vous ne savez pas, c’est que Linux convient.

En heures ouvrées, le support répond et prend la main à distance si nécessaire ; en dehors, une astreinte peut être appelée pour un problème grave. Sur ces offres, nous nous engageons sur une garantie de temps de rétablissement de 4 heures — un engagement de délai, à ne pas confondre avec une promesse qu’il ne se passera jamais rien.

Oui, à Saint-Herblain en Loire-Atlantique, dans le datacenter Etix Ouest, là où se trouvent aussi nos bureaux. La plateforme n’est composée que de serveurs qui nous appartiennent et que nous gérons de bout en bout : il n’y a ni intermédiaire technique, ni sous-traitance.

D’abord en n’hébergeant aucun site susceptible de mettre les autres en danger, et en plaçant un pare-feu applicatif devant chacun. Ensuite en sachant ce qui se passe : deux extensions PHP que nous avons développées en interne — weobia_reguard, qui note chaque script pour repérer les fichiers malveillants, et weobia_mailhook, qui trace les e-mails site par site et script par script. Un voisin compromis se traite alors en heures, pas en jours.

Hébergement mutualisé Linux →

Oui. Vous avez un accès administrateur à Plesk ou cPanel selon l’offre, d’où vous gérez les comptes e-mail, les mots de passe, les bases de données et l’installation de WordPress. Et si vous préférez ne pas y toucher, notre support répond sur un numéro direct non surtaxé.

Accompagnement à la gestion →

La souplesse. Sur un compte revendeur, vous ne choisissez pas telle version de logiciel ni telle configuration particulière : c’est nous qui les gérons. En contrepartie, vous commencez à héberger l’ensemble de vos clients à moindre coût, sans devenir administrateur système.

Serveurs privés →

Non, et c’est le rôle de CloudLinux : il garantit les ressources de chacun et isole les sites les uns des autres. Sans cela, le site le plus mal tenu de votre parc dicterait la vitesse de tous les autres — et une attaque contre l’un pourrait atteindre les suivants.

À partir de 99 € HT par mois, la facturation suivant les ressources allouées — mémoire, disque, processeur. Il n’y a pas d’engagement minimal, et la livraison est clé en main. À vous ensuite de composer vos propres packs pour vos clients finaux.

Entièrement. Vous gérez vos clients depuis votre panneau, vous composez vos offres, vous facturez. Nous n’intervenons que sur la plateforme — créer des sites est votre métier, la technique est le nôtre.

Vos comptes en profitent automatiquement. Stockage intelligent qui place les données les plus utilisées en mémoire vive, pare-feu applicatif dont les règles referment les failles connues, alternative à Apache plus réactive sur les pages PHP comme statiques : rien à demander, rien à migrer.

Non, c’est même le principe : nous vous accompagnons sur l’hébergement que vous avez déjà. OVH, Scaleway, 1&1, Ikoula, et tout hébergeur proposant Plesk ou cPanel. Rien à déplacer, rien à interrompre.

Un abonnement modeste et une relation qui dure. Notre volonté est que vous utilisiez au mieux votre hébergement, y compris s’il n’est pas le nôtre — et si vous décidez un jour de venir, le transfert est gratuit. Nous préférons cela à vous verrouiller.

C’est fréquent, et rarement dans votre intérêt : cela assure un revenu récurrent et verrouille la relation, le plus souvent en sous-traitant chez un hébergeur grand public. Nous vous aidons à regagner cette liberté — vous gardez le choix de l’hébergeur et le choix de l’agence.

Parce que ses conditions générales vous rappellent que la copie de sauvegarde est votre responsabilité, en toutes circonstances — et parce qu’une sauvegarde stockée chez celui qu’elle est censée couvrir n’en est pas tout à fait une. L’espace FTP de 1 Go inclus, extensible, est totalement indépendant de lui.

Sauvegarde distante →

Oui. Nous revendons directement les packs des hébergeurs grand public : nous prenons alors en charge la facturation, et vous disposez comme nous d’un accès administrateur au compte. Vous ne perdez donc pas la main sur votre propre hébergement.

Plus souvent qu’on ne le croit, oui : la charge d’un ERP vient d’une équipe interne, pas d’un trafic public. Nos serveurs mutualisés hébergent déjà des CRM comme Dolibarr ou SugarCRM et des ERP. Trois choses justifient de passer à une machine dédiée : des traitements lourds et longs, un besoin de configuration que la plateforme partagée ne permet pas, ou des échanges permanents avec d’autres logiciels.

Serveurs privés →

Non. La plateforme supporte toutes les versions de PHP sous Linux, de PHP 4 à PHP 8. Une installation ancienne peut donc être reprise telle quelle puis mise à niveau ensuite, plutôt que d’imposer une migration comme préalable à l’hébergement — ce qui reviendrait à faire deux chantiers difficiles en même temps.

Rarement en totalité. C’est un outil interne : nous restreignons l’accès par filtrage d’adresses, avec un accès distant pour ceux qui en ont besoin et un second facteur d’authentification. C’est la mesure la plus efficace et la plus souvent négligée, parce qu’elle retire la page de connexion de la vue de tout internet.

Sécurisation du SI →

Quotidiennement, avec une conservation de 30 jours et une réplication hors du serveur qu’elle protège. Sur un logiciel de gestion, le risque le plus fréquent n’est pas la panne mais la fausse manœuvre : un import qui écrase un fichier client, une suppression en masse faite de bonne foi. La question qui compte est le temps de restauration, et nous le connaissons parce que nous la testons.

Sauvegarde distante →

L’exploitation du serveur est à notre charge. Pour l’application, cela dépend de qui l’a installée et de ce qu’elle contient comme adaptations : c’est justement pour que ces mises à jour restent possibles que nous développons des modules plutôt que de modifier le cœur du logiciel. Ce point se cadre au démarrage, pas au moment de la première alerte de sécurité.

Développement CRM / ERP →

À Nantes et dans d’autres centres de données en France. Les données qui nous sont confiées sont les vôtres, restent confidentielles, et les seules lois qui s’y appliquent sont françaises et européennes. Pour un fichier client et un historique de facturation, c’est souvent le critère qui tranche. Nos machines sont nantaises ; nos clients, eux, sont dans toute la France — l’hébergement et le support se pilotent à distance.

Deux raisons, et elles n’ont rien à voir. Le droit applicable d’abord : un service opéré depuis l’étranger y reste soumis, et votre GitLab contient le code, les discussions techniques et les secrets d’accès à votre production. La structure de coût ensuite : la facturation par utilisateur et par minute de build augmente précisément quand l’équipe produit le plus.

Oui : GitLab dispose d’un mécanisme d’export et d’import qui transporte les dépôts, l’historique, les tickets et les demandes de fusion. Le volume et la version d’origine déterminent la durée réelle de l’opération — nous la regardons avant de nous engager sur un délai.

Pas en minutes : les exécuteurs tournent sur votre instance, donc la seule limite est la capacité de la machine. C’est justement ce qu’il faut dimensionner correctement — une chaîne de build est plus gourmande que l’usage quotidien des dépôts, et par à-coups.

Serveurs privés →

Nous. GitLab publie régulièrement des correctifs, dont des correctifs de sécurité, et une instance laissée en arrière devient une porte ouverte — d’autant qu’elle donne accès à votre production. L’installation, les mises à jour et la supervision sont à notre charge.

Vous partez avec tout. GitLab est un logiciel libre et vos données sont exportables par ses propres mécanismes : ni format fermé, ni dépendance qui rendrait le départ impossible. C’est la même règle que sur nos autres hébergements — les données sont les vôtres.

Alors une instance complète est peut-être surdimensionnée, et nous vous le dirons. GitLab prend tout son sens quand la chaîne de build, le registre d’images et le suivi des tickets vivent au même endroit que le code. Pour du simple stockage de fichiers partagés, c’est vers un autre outil qu’il faut regarder.

Hébergement NextCloud →

La sauvegarde vous permet de revenir en arrière ; la haute disponibilité évite d’avoir à le faire. Une restauration prend des minutes ou des heures pendant lesquelles le service est arrêté. Une bascule prend quelques secondes et ne se voit pas depuis l’extérieur. Les deux sont utiles, et pour des raisons différentes.

Sauvegarde distante →

Cela dépend de l’architecture retenue, et cela se calcule — pas se promet à l’avance. Un chiffre annoncé sans dire de quoi il parle n’engage à rien : un serveur redondé devant une base unique n’est pas hautement disponible. Nous chiffrons l’engagement une fois l’architecture arrêtée. Sur nos offres mutualisées, un engagement existe déjà : une garantie de temps de rétablissement de 4 heures.

Hébergement mutualisé →

Souvent, oui, et c’est la partie qu’on découvre tard. Une application qui garde les sessions en mémoire d’un serveur, ou qui écrit des fichiers en local, ne supporte pas d’être dupliquée telle quelle. Nous le regardons avant de dimensionner quoi que ce soit : dupliquer une application qui ne s’y prête pas coûte cher et ne protège de rien.

Non, mais cela se justifie par le coût d’une interruption, pas par la taille du site. Une boutique qui perd une journée de commandes ou un extranet dont dépendent des équipes en atelier ont un intérêt évident. Un site vitrine, rarement — le mutualisé, avec sa garantie de rétablissement, y répond mieux et pour moins cher.

Ce n’est pas le même problème, même s’il se traite avec des outils voisins. Encaisser un pic relève du dimensionnement et du cache ; survivre à une panne relève de la redondance. Une architecture bien faite fait les deux, mais on ne les chiffre pas de la même façon.

Sites à fort trafic →

Deux raisons distinctes. Le droit applicable : un service opéré depuis l’étranger y reste soumis, et votre messagerie accumule des arbitrages, des échanges clients et des accès envoyés « en attendant ». La structure de coût ensuite : la facturation par utilisateur augmente avec l’effectif, et l’historique — la partie qui prend de la valeur — est souvent la première limitée.

Mattermost dispose d’un mécanisme d’import Slack, qui transporte les canaux et les messages. Le volume et l’ancienneté déterminent la durée réelle de l’opération : nous la regardons avant de nous engager sur un délai.

Peu : l’organisation en canaux, fils et messages directs est celle des outils du marché, et il existe des applications de bureau et mobiles. Le changement porte sur l’adresse de connexion bien plus que sur les habitudes.

Nous. Comme pour toute instance exposée sur internet, les correctifs de sécurité arrivent par les mises à jour, et une instance laissée en arrière devient une porte ouverte sur des conversations sensibles. L’installation, les mises à jour et la supervision sont à notre charge.

Vous partez avec tout : Mattermost est un logiciel libre et vos données sont exportables. Ni format fermé, ni dépendance qui rendrait le départ impossible — c’est la même règle que sur nos autres hébergements.

Parce que ce CMS a des besoins précis : une version de PHP récente, un cache de pages, souvent un cache objet, et une gestion des processus adaptée. Un hébergement spécifique réunit ces réglages d’emblée, au lieu de vous laisser les installer plugin par plugin.

Les mêmes garanties de ressources et la même infrastructure, plus les extensions que nous mettons à disposition — dont le cache LiteSpeed — et les réglages propres à WordPress. Ces extensions ne sont pas facturées en supplément.

Oui, selon la formule. Attention à un point : les ressources sont garanties pour le compte, pas par site. Plusieurs sites sur un même compte se les partagent entre eux — ce qui reste bien plus prévisible qu’un partage avec des clients inconnus.

À partir de 9 € HT par mois : l’hébergement à ressources dédiées et garanties, le cache LiteSpeed sans licence à acheter, les extensions que nous mettons à disposition, le certificat SSL, le pare-feu applicatif, la sauvegarde quotidienne conservée 30 jours et le support téléphonique. La migration depuis votre hébergeur actuel est comprise.

Oui, nous nous en chargeons. Le nouveau site est monté et vérifié pendant que l’ancien continue de servir : la bascule ne dure que le temps d’un changement de DNS, et le site n’est jamais indisponible. Nous conservons les adresses des pages — c’est le point qui décide de ce que devient votre référencement.

WordPress est la cible favorite des attaques automatisées, qui exploitent presque toujours une faille connue et corrigée depuis des mois. Le pare-feu applicatif est en amont du site, ses règles sont mises à jour très régulièrement, et une faille découverte est corrigée virtuellement en attendant votre mise à jour. C’est exactement l’intervalle où la plupart des sites se font prendre.

Sécurisation de site web →

En heures ouvrées le support répond et prend la main à distance si nécessaire ; en dehors, une astreinte peut être appelée. Nous nous engageons sur une garantie de temps de rétablissement de 4 heures, et la sauvegarde quotidienne conservée 30 jours permet de revenir en arrière si le problème vient du site lui-même.

Le WordPress Toolkit de Plesk vous permet de gérer les mises à jour du cœur et des extensions depuis l’interface. Si vous préférez ne pas vous en occuper, c’est une prestation d’accompagnement à part.

Accompagnement — mutualisé co-géré →

Techniquement, assez peu : synchroniser des fichiers est un problème résolu. Juridiquement, beaucoup. Un service opéré par une société soumise à un droit étranger le reste, où que soient ses machines. Ici, vos données sont hébergées en France et les seules lois qui s’y appliquent sont françaises et européennes.

Le logiciel est libre : vous n’achetez pas de licence par utilisateur, et vous ne dépendez d’aucune décision d’éditeur sur son prix ou son avenir. Ce que nous facturons, c’est l’hébergement et l’exploitation — l’installation, les mises à jour, la supervision et la sauvegarde de l’infrastructure.

Non, et c’est une confusion fréquente. Une synchronisation propage aussi les suppressions : un fichier effacé disparaît de tous les appareils, c’est son fonctionnement normal. Ce qui permet de revenir en arrière, c’est la sauvegarde de l’infrastructure. Pour protéger des postes ou des serveurs entiers, c’est une prestation de sauvegarde qu’il faut.

Sauvegarde distante →

Oui. L’accès se fait depuis un navigateur, et des applications de bureau et mobiles synchronisent les dossiers avec vos appareils. Un document déposé depuis un poste est disponible sur les autres sans manipulation.

Nous. L’installation, les mises à jour et la supervision sont à notre charge : c’est le principe de nos hébergements, vous n’avez pas de machine à administrer. Si vous voulez au contraire garder la main sur un serveur qui vous est propre, c’est vers un serveur privé qu’il faut regarder.

Serveurs privés →

Non. Nos serveurs tournent sous LiteSpeed et le plugin de cache LiteSpeed est fourni gratuitement avec l’hébergement. C’est une dépense que beaucoup d’hébergeurs vous laissent assumer — les extensions de cache du marché se paient en général par site et par an. Et la mise en cache est ici faite par le serveur lui-même, donc plus rapide qu’une extension qui s’exécute dans PHP.

Par weobia_mailhook, une extension PHP que nous avons développée en interne et qui trace les e-mails envoyés, site par site et script par script. Quand du spam part d’un compte — le plus souvent depuis un site compromis à l’insu de son propriétaire — nous savons lequel et par quel fichier, au lieu de suspendre le compte entier en attendant de comprendre.

Par weobia_reguard, notre seconde extension maison, qui attribue un score à chaque script pour repérer les fichiers malveillants. Elle complète le pare-feu applicatif : celui-ci bloque ce qui essaie d’entrer, elle trouve ce qui est déjà là. Ces deux extensions sont exclusives — elles ne sont disponibles chez aucun autre hébergeur.

Oui, jusqu’à cinq sur la formule à 110 € HT par an, et sans limite sur la formule Illimité. C’est une vraie économie : un hébergement payé au lieu de cinq, une seule interface et une seule facture. Deux contreparties à connaître : les sites d’un même compte se partagent son allocation de processeur et de mémoire, et si l’un est compromis les autres peuvent l’être aussi. Notre règle : regroupez ce qui peut tomber ensemble, et donnez son propre compte au site qui compte vraiment.

Autant que vous voulez, sur les quatre formules : le nombre de noms de domaine n’est pas limité. Ce n’est pas la même chose que le nombre de sites, lui borné par la formule — un même site peut parfaitement répondre sur plusieurs domaines, par exemple pour couvrir une extension .fr et une .com, ou rediriger d’anciennes adresses vers la nouvelle.

Nom de domaine →

Cela dépend de la formule, et mieux vaut le savoir avant. Sur les formules 1 Go et 2 Go, l’espace consommé au-delà est facturé au gigaoctet. Sur la formule 10 Go, le dépassement est libre et n’entraîne aucun surcoût — en contrepartie, le support technique est suspendu tant qu’il dure. Sur la formule Illimité, la question ne se pose pas.

Que le processeur et la mémoire annoncés vous sont attribués, et pas partagés avec les autres comptes du serveur. Chaque site est isolé par CloudLinux : il fonctionne comme s’il disposait de son propre petit serveur. C’est l’inverse du modèle low-cost, où la limite affichée est une limite théorique.

Oui, quotidiennement, avec 30 jours de rétention. La restauration se demande au support. En complément, les données sont écrites deux fois sur deux espaces disques indépendants — ce qui couvre la panne matérielle, mais ne remplace pas la sauvegarde.

Le serveur LiteSpeed apporte un cache intégré, ce qui évite d’acheter une licence de plugin de cache. Le WordPress Toolkit de Plesk gère les mises à jour et les clones. Nous avons aussi des offres pensées spécifiquement pour ce CMS.

Hébergement WordPress →

La plateforme est surveillée par deux systèmes de supervision distincts, dont un externe, et les temps de réponse sont mesurés depuis plusieurs pays. En heures ouvrées, le support répond au téléphone ; en dehors, une astreinte prend le relais.

Oui. Prestashop et Magento sont supportés, et le module LiteSpeed correspondant accélère les temps de réponse sans surcoût. Pour une boutique à fort trafic, nous regardons ensemble si le mutualisé suffit ou si un serveur dédié est plus adapté.

Il n’y a pas de seuil chiffré, et se fier à un nombre de visiteurs induit en erreur. Trois symptômes comptent : les pages ralentissent aux heures de pointe seulement, la base devient le goulot et le cache de page n’y change plus rien, ou une opération commerciale concentre en deux heures le trafic d’un mois.

Parfois si, souvent non. Quand la base est le goulot, doubler le processeur ne fait que déplacer l’attente. La réponse est alors une architecture différente : un cache au bon endroit, une base spécialisée pour la recherche, une file pour sortir les traitements lourds du temps de réponse. C’est ce que nous regardons avant de dimensionner.

La haute disponibilité est native sur notre cluster : en cas d’avarie sur un nœud de traitement, un autre reprend l’exécution de votre machine virtuelle. Pour les besoins les plus exigeants, deux datacenters physiques sont unifiés virtuellement pour n’en former qu’un.

Hébergement haute-disponibilité →

Sur mesure : le tarif dépend entièrement des ressources et de l’architecture retenues. Nous chiffrons après avoir regardé l’application, pas avant — annoncer un prix sans savoir ce que fait le code reviendrait à le deviner.

Pas forcément, et nous vous le dirons. Le mutualisé à ressources dédiées couvre la grande majorité des sites, y compris des boutiques ; un serveur privé répond au besoin de choisir sa configuration. Le fort trafic commence là où une machine seule ne suffit plus. Décrivez-nous votre trafic réel : il arrive que la réponse soit le palier d’en dessous.

Hébergement mutualisé →

Non. Next.js est un logiciel libre et s’héberge où vous voulez. Une partie de son confort vient toutefois de cette plateforme — cache réparti, régénération, optimisation des images — et il faut remplacer ces éléments consciemment plutôt que les découvrir absents en production. C’est ce que nous faisons à la mise en service.

Si toutes les pages peuvent être connues à l’avance, oui — et c’est le cas le plus économique : des fichiers sur notre mutualisé, dès 72 € HT par an, qui encaissent les pics sans broncher. Dès qu’une page dépend de l’utilisateur connecté, il faut un serveur. Le mode mixte est le plus fréquent.

Hébergement mutualisé Linux →

En rendu serveur, aucune sur le principe : c’est une application Node, avec superviseur, reverse proxy et plafond de mémoire. La différence tient aux trois points propres à Next.js — le cache des images, la régénération des pages et le cache partagé entre instances — qui doivent être traités explicitement.

Hébergement Node.js →

Non, et c’est une différence de fond avec une plateforme facturée à l’usage : vous payez une machine, pas des visites ni des fonctions exécutées. La facture est prévisible, et elle n’augmente pas le jour où un article marche mieux que prévu.

Serveurs privés →

Oui. Next.js fait partie des outils du sur-mesure que nous employons, aux côtés de Gatsby dans l’écosystème React. Avoir le développement et l’exploitation au même endroit évite de se renvoyer la balle quand quelque chose ralentit.

Développement Next.js →

Non, et ce n’est pas une limite de notre offre mais la nature de la technologie : une plateforme mutualisée exécute un script à l’arrivée d’une requête puis l’oublie, alors qu’une application Node reste en mémoire en permanence. Il lui faut un serveur privé ou un conteneur.

Serveurs privés →

Elle est relancée automatiquement par le superviseur, et l’incident remonte à nos outils : en cas d’alerte ils corrigent d’abord, puis préviennent un administrateur d’astreinte. Un processus qui redémarre en boucle sans que personne le sache est un incident en préparation, pas une solution.

Le serveur privé est le plus simple, et suffit à la plupart des projets. Le conteneur se justifie quand vous déployez souvent, quand plusieurs environnements doivent être strictement identiques, ou quand plusieurs applications doivent cohabiter sans se gêner.

Hébergement Docker →

En faisant tourner plusieurs instances derrière le proxy et en les remplaçant l’une après l’autre. Deux conditions côté application : qu’elle ne garde rien en mémoire qui doive survivre à une requête, et qu’elle s’arrête proprement quand on le lui demande.

Oui — nous employons Node.js principalement sur les projets qui doivent traiter un nombre important de requêtes simultanées. Avoir le développement et l’exploitation au même endroit évite de se renvoyer la balle quand quelque chose ralentit.

Développement Node.js →

Posez-vous cette question : deux visiteurs différents voient-ils la même page ? Si oui, elle peut être générée à l’avance, et l’hébergement devient trivial. Si non — espace client, contenu personnalisé — il faut une machine. Beaucoup de projets partent en rendu serveur par habitude alors que l’essentiel de leurs pages est identique pour tout le monde.

Oui, et c’est souvent la meilleure réponse : générer les pages publiques et ne rendre à la demande que la partie connectée. On garde l’hébergement léger sur l’essentiel du trafic et la souplesse là où elle est nécessaire.

Sans difficulté, et c’est même le cas idéal : servir des fichiers ne consomme ni processeur ni mémoire, donc le site encaisse des pics qui feraient plier une application classique. Nos formules démarrent à 72 € HT par an.

Hébergement mutualisé Linux →

Les mêmes choses que pour toute application Node.js : un superviseur qui relance le processus, un reverse proxy devant, une limite de mémoire explicite et des journaux sortis du processus. Nous mettons l’ensemble en place et nous l’exploitons.

Hébergement Node.js →

Non : une application Python est un programme qui tourne en permanence, alors qu’une plateforme mutualisée exécute un script à l’arrivée d’une requête puis l’oublie. Il lui faut un serveur privé ou un conteneur.

Serveurs privés →

En figeant les versions de l’interpréteur et de toutes les bibliothèques — y compris celles installées indirectement — et en rendant l’installation reproductible à l’identique. C’est ce qui permet de remonter le serveur après un incident et d’obtenir exactement la même application.

Seulement si elle est servie par un serveur ASGI. C’est une erreur de configuration silencieuse et fréquente : l’application fonctionne, mais elle perd tout l’avantage de son architecture asynchrone, et cela ne se voit qu’en charge. Nous le vérifions à la mise en service.

Développement Python →

Pas obligatoirement, mais c’est là que le conteneur apporte le plus : l’image fige l’environnement une fois pour toutes, ce qui règle la principale difficulté d’exploitation d’une application Python. À considérer si vous déployez souvent.

Hébergement Docker →

Cela dépend de l’application, et c’est précisément ce que nous mesurons plutôt que d’estimer : la consommation d’une JVM en charge réelle est la seule donnée qui vaille. Ce qui est certain, c’est qu’il faut un plafond explicite — sans lui, la JVM prend tout et le système finit par tuer le processus.

Oui, à condition de fixer le plafond de mémoire en tenant compte de la limite du conteneur, faute de quoi le processus sera tué sans erreur applicative. La compilation native via GraalVM rend l’exercice bien plus confortable : démarrage quasi instantané et empreinte réduite.

Hébergement Docker →

Une machine, oui — serveur privé ou conteneur : une application Spring Boot tourne en permanence et ne peut pas vivre sur une plateforme mutualisée. Nous l’exploitons pour vous : mises à jour, supervision, correction automatique sur alerte et astreinte.

Serveurs privés →

En faisant tourner plusieurs instances derrière le proxy et en les remplaçant l’une après l’autre. Le temps de démarrage devient alors un vrai sujet : c’est l’un des arguments les plus concrets en faveur de la compilation native.

Haute disponibilité →

Dans la grande majorité des cas, oui — à condition que les ressources soient réellement dédiées, ce qui est notre cas. Une application Symfony consomme d’abord du processeur et de la mémoire ; sur un mutualisé sur-réservé, elle subit la charge des voisins. C’est exactement ce que nos offres évitent.

Hébergement mutualisé Linux →

La plateforme supporte toutes les versions de PHP sous Linux, de PHP 4 à PHP 8. Si votre application exige une extension particulière que nous ne fournissons pas, c’est l’un des trois cas où un serveur privé devient nécessaire.

Serveurs privés →

Les tâches planifiées sont prévues. Pour des traitements longs ou des files de messages — des ouvriers qui tournent en permanence — un serveur privé est plus adapté : c’est le deuxième signal qui fait quitter le mutualisé.

En heures ouvrées le support répond et prend la main à distance si nécessaire ; en dehors, une astreinte peut être appelée. Sur ces offres nous nous engageons sur une garantie de temps de rétablissement de 4 heures — un engagement de délai, à ne pas confondre avec une promesse qu’il ne se passera rien.

Oui, et c’est l’intérêt d’avoir les deux au même endroit : personne ne se renvoie la balle quand quelque chose est lent. Nous employons Symfony notamment pour des extranets et des intranets destinés à des équipes qui veulent rester sur PHP.

Développement Symfony →

Oui. Il est enregistré à votre nom auprès du registre, et vous pouvez le transférer chez un autre prestataire quand vous le voulez. Nous facturons des frais fixes de transfert sortant, destinés à vous accompagner pour que l’opération ne coupe ni vos e-mails ni votre site.

Le tarif comprend 10 redirections e-mails, protégées par antivirus et anti-spam : de quoi recevoir sur une adresse existante à votre nom de domaine. Pour de vraies boîtes aux lettres, avec envoi, agenda et contacts, il faut une offre de messagerie.

Hébergement d’e-mails →

Le .fr si votre activité est française : il est bien perçu et bien référencé localement. Le .com si vous visez l’international ou si vous voulez protéger votre marque. Les extensions régionales comme .bzh ou .alsace ont du sens quand l’ancrage local est votre argument. Dans le doute, appelez-nous : le conseil est gratuit.

Nous renouvelons le domaine automatiquement, 30 jours avant sa date d’expiration, et nous prenons en charge les formalités auprès des registrars et des registres. C’est délibérément anticipé : il n’y a pas de période de grâce pour rattraper un nom laissé expirer, et un domaine perdu peut être repris par n’importe qui dans la minute. Si vous ne souhaitez pas reconduire un nom, prévenez-nous avant ce délai de 30 jours.

L’enregistrement auprès du registre est quasi immédiat. Ce qui prend un peu de temps, c’est la propagation : les serveurs DNS du monde entier mettent de quelques minutes à quelques heures à connaître votre zone. Tant qu’elle n’est pas propagée partout, le site peut s’afficher chez vous et pas encore chez votre voisin.

Oui, et c’est l’usage dès qu’un nom compte : on réserve les extensions voisines et les orthographes proches en même temps. Au-delà de quelques dizaines de noms, nous assurons la gestion de l’ensemble du portefeuille — échéances, zones DNS et titularité comprises.

Gestion de portefeuille →

Non. La réservation vous donne l’usage du domaine, pas un droit sur le nom lui-même : c’est le dépôt de marque à l’INPI qui protège celui-ci. Un domaine peut être disponible tout en heurtant une marque existante — d’où l’intérêt de vérifier avant de réserver. Nous vous orientons sur ce point, le conseil est gratuit.

Oui. Il faut le code de transfert fourni par votre prestataire actuel, et que le domaine ne soit pas verrouillé. Nous préparons l’opération avec vous pour éviter toute coupure de site ou de messagerie pendant la bascule.

Non. Nous pouvons gérer un portefeuille réparti chez plusieurs registrars — Gandi, OVH, BookMyName et d’autres. C’est souvent l’obstacle qui fait renoncer à centraliser ; il n’en est pas un ici. Les transferts entrants, si vous en souhaitez, font partie de la prestation.

Non : la facturation suit notre grille tarifaire de noms de domaine, sans frais supplémentaire pour la gestion du portefeuille. Des tarifs dégressifs s’appliquent selon la quantité de noms enregistrés.

Nom de domaine →

C’est précisément ce que la gestion évite. Le renouvellement est automatique et intervient 30 jours avant l’échéance : nous ne comptons pas sur une période de grâce, qui n’existe pas sur toutes les extensions et se paie cher quand elle existe.

Oui, c’est la partie technique de la prestation : zones DNS, redirections transparentes ou non, et les enregistrements qui vont avec — ceux de la messagerie compris. Le support répond aussi aux questions de configuration, gratuitement.

Oui : la récupération et la surveillance de noms de domaine font partie de l’offre. Savoir qu’un nom proche du vôtre vient d’être déposé, ou qu’un domaine convoité redevient disponible, suppose de regarder tous les jours — c’est le genre de veille qu’on ne tient pas soi-même très longtemps.

Le virtuel suffit à la plupart des projets exigeants, et il a un avantage souvent décisif : il tourne sur un cluster, donc il survit à la panne du matériel qui le porte. Le dédié se justifie quand l’isolation doit être matérielle, quand l’application exploite directement le matériel, ou quand la charge dépasse ce qu’une partition absorbe.

Serveurs privés →

Non, et c’est contre-intuitif : il l’est plutôt moins. Une machine virtuelle sur cluster est reprise par un autre nœud si le matériel lâche. Un dédié est un seul morceau de matériel — s’il tombe, il tombe. Sa redondance se construit en doublant la machine, ce qui relève de l’architecture haute disponibilité.

Haute disponibilité →

Non, nos serveurs dédiés sont infogérés : installation, mises à jour, supervision, correction automatique sur alerte et astreinte. Les conditions d’intervention sont celles de notre offre d’infogérance, la même que pour un serveur resté chez un autre fournisseur.

Infogérance Plesk / cPanel →

Rarement, et nous le dirons. Nos offres mutualisées reposent déjà sur des ressources dédiées et garanties, sans sur-réservation : un site voisin ne peut pas ralentir le vôtre. Le passage au serveur se justifie par la configuration, la charge ou une contrainte d’isolation — pas par principe.

Hébergement mutualisé →

Deux choses. La configuration d’abord : en mutualisé, c’est nous qui fixons les versions de logiciels et les réglages ; sur un serveur privé, vous les choisissez. Les ressources ensuite : elles vous sont constantes, ce qui donne de meilleurs temps de réponse. En contrepartie, la machine coûte plus cher et demande à être exploitée — ce dont nous nous chargeons.

Hébergement mutualisé →

Non. Le serveur est infogéré : mises à jour, surveillance des métriques, correction automatique sur alerte et administrateur d’astreinte si le problème est plus grave. Les conditions d’intervention — forfait mensuel, heures décomptées, astreinte hors heures ouvrées — sont celles de notre offre d’infogérance.

Infogérance Plesk / cPanel →

Un serveur virtuel — une partition de machine avec des ressources garanties — suffit à la plupart des projets exigeants. Le dédié, une machine physique entière, se justifie quand la charge, l’isolation ou une contrainte matérielle le commandent. Nous tranchons à partir de votre trafic réel et de ce que demande votre application.

Non. Le serveur reste dans notre infrastructure anti-spam et antivirus, et nos deux extensions PHP développées en interne y sont également déployables : weobia_mailhook, qui trace les e-mails site par site et script par script pour identifier un site compromis, et weobia_reguard, qui attribue un score à chaque script pour repérer les fichiers malveillants. C’est ce qui distingue une machine infogérée d’un serveur nu loué ailleurs.

Hébergement mutualisé Linux →

Oui, et c’est le point important : une sauvegarde qui vit sur le serveur qu’elle protège ne protège de rien. Nous répliquons les données sur une infrastructure distincte de celle qui héberge le serveur — par R1Soft vers celle de notre partenaire Devclic, à Strasbourg.

Sauvegarde distante →

Nos équipes vous aident à optimiser le fonctionnement du site. C’est ce que nous faisons pour PrimHolstein France, dont le site et les applications tournent sur un serveur privé que nous gérons. Ajouter de la machine est le dernier recours, pas le premier réflexe.

Oui, c’est un usage courant : nous exploitons plusieurs serveurs pour des agences web, avec la protection des sites sensibles et notre infrastructure anti-spam et antivirus sur l’ensemble. Si le volume ne le justifie pas encore, l’offre mutualisée pour agence est le premier palier.

Hébergement pour agence web →

Pas pour le cas courant : Let’s Encrypt est inclus et automatique dans toutes nos offres d’hébergement, et il suffit à un site vitrine ou à un blog. Un certificat payant se justifie quand il faut valider votre organisation et pas seulement votre domaine — une boutique, un espace client, tout ce qui manipule un paiement.

Certificats SSL →

Oui, c’est précisément l’objet de l’offre d’infogérance. Le serveur reste chez votre fournisseur — OVH, Scaleway, Ikoula ou un autre — et nous reprenons le panneau Plesk ou cPanel et l’administration de la machine. Vous n’avez ni migration à faire, ni contrat à résilier.

Infogérance Plesk / cPanel →

L’hébergement mutualisé n’en a pas besoin : c’est nous qui tenons la plateforme, et vous n’avez aucune machine à administrer. La question se pose sur un serveur privé, où l’exploitation relève des mêmes conditions que l’offre d’infogérance.

Serveurs privés →

Pour un site vitrine ou un blog, oui : le chiffrement est le même, et c’est ce qui protège les échanges. Ce que Let’s Encrypt ne fait pas, c’est vérifier qui vous êtes — il atteste seulement que vous contrôlez le domaine. Dès qu’il y a paiement ou données personnelles, la validation d’organisation a une vraie valeur.

Non pour les certificats GlobalSign : ils sont indépendants de votre hébergeur et nous nous chargeons des démarches et de l’installation. Let’s Encrypt en revanche est inclus et automatisé dans nos propres offres d’hébergement, via le panneau Plesk.

Hébergement mutualisé →

Un certificat à validation étendue, avec un contrôle d’identité plus poussé de l’entreprise. Nous savons en mettre en place, mais cela sort du catalogue standard : appelez-nous pour en discuter.

Nous contacter →

Pour Let’s Encrypt, directement depuis le panneau Plesk : le processus est entièrement automatisé et le support technique reste disponible si besoin. Pour les autres, passez par le service commercial, qui prend en charge tout le processus — et précisez si vous avez besoin d’une passerelle SSL.

cPanel si vous revendez de l’hébergement ou si plusieurs clients doivent avoir chacun leur accès : WHM est fait pour ça. Plesk dès qu’une machine Windows entre dans le parc, puisque cPanel ne tourne que sous Linux. En dehors de ces deux cas, prenez celui que votre équipe pratique déjà.

Infogérance Plesk →

Non, et votre licence cPanel non plus. Le serveur reste chez votre fournisseur, vous gardez votre contrat : nous intervenons dessus, rien de plus.

L’offre et ses tarifs →

Non, elle se souscrit auprès de l’éditeur ou de votre fournisseur, et son tarif dépend du nombre de comptes hébergés. C’est un point à regarder avant de multiplier les comptes sur une même machine : la facture suit leur nombre, pas la taille du serveur.

Oui, WHM sait transférer un compte entier — fichiers, bases, boîtes e-mail, réglages — vers un autre serveur cPanel. C’est l’un de ses points forts, et ce qui rend une montée en charge moins pénible qu’ailleurs.

Oui, et c’est l’un des moments où cette prestation se justifie le plus. Une montée de version touche au serveur web, à PHP et aux bases de données en même temps ; c’est là que les sites tombent.

Non, et c’est tout l’intérêt de cette prestation. Votre serveur reste chez votre fournisseur actuel — OVH, Scaleway, Ikoula ou un autre — et vous gardez votre contrat. Nous intervenons dessus, c’est tout.

Nous prenons contact avec vous pour convenir d’un forfait d’heures supplémentaires. Nous ne laissons pas courir la facturation sans vous prévenir : c’est une prestation au temps passé, et vous devez pouvoir l’arbitrer.

Le forfait de base couvre les heures ouvrées. Une option d’astreinte 24h/24 permet de déclencher un appel ou un ticket en dehors — utile pour un site e-commerce ou une application critique, superflu pour un serveur de site vitrine.

Oui, la migration vers une nouvelle version des panneaux est prise en compte dans la prestation. C’est souvent le moment le plus risqué de la vie d’un serveur, et c’est précisément celui où il vaut mieux ne pas être seul.

Sous Windows, Plesk : son concurrent ne tourne pas dessus. Si vous revendez de l’hébergement et que chaque client doit avoir son accès, cPanel et son WHM sont plus directs. En dehors de ces deux cas, prenez celui que votre équipe pratique déjà — c’est le critère qui compte le plus au quotidien.

Comparer les deux →

Sous Windows, Plesk, sans discussion : son concurrent ne tourne pas dessus. Sous Linux, la question est ouverte et se tranche sur ce que votre équipe pratique déjà et sur ce que le serveur porte. Si vous revendez de l’hébergement à des clients qui ont chacun leur accès, cPanel et son WHM sont plus directs.

Infogérance cPanel →

Non. Votre serveur reste chez votre fournisseur — OVH, Scaleway, Ikoula ou un autre — et vous gardez votre contrat. Nous intervenons dessus, c’est tout.

L’offre et ses tarifs →

Elle dépend de votre fournisseur : beaucoup la proposent avec le serveur, à un tarif lié au nombre de domaines. Nous regardons ce que vous payez déjà avant d’en ajouter une — il arrive qu’une licence soit facturée deux fois sans que personne ne s’en aperçoive.

Oui, et c’est l’un des moments où cette prestation se justifie le plus. Une montée de version de panneau touche au serveur web, à PHP et aux bases de données en même temps ; c’est là que les sites tombent.

Oui, Plesk fournit un outil de migration qui reprend comptes, sites, bases et boîtes e-mail. Le transfert n’est jamais la partie difficile : ce sont les réglages qui ne se transposent pas — règles de réécriture, tâches planifiées, certificats — et c’est là que passe le temps.

Sur le support, aucune : c’est la même technologie mutualisée. La différence se joue sur l’accompagnement — un interlocuteur qui connaît aussi votre hébergement et vos applications, plutôt qu’un service client généraliste. Si vous cherchez une différence technique, c’est vers le dédié qu’il faut regarder, pas vers un FTTH « pro ».

Par une étude, et elle est gratuite. Le délai de raccordement dépend entièrement de votre adresse et de ce qui existe déjà dans la rue : court si le génie civil est en place, plusieurs mois s’il faut creuser. L’étude répond à cette question avant tout engagement.

Oui, et c’est un chemin fréquent. Le lien mutualisé peut même être conservé comme secours une fois le dédié en place : deux liens de supports différents valent mieux qu’un seul, et l’agrégation bascule automatiquement de l’un à l’autre.

Fibre dédiée FTTO →

Non. Le réseau de notre partenaire opérateur couvre le territoire, et les collectes dont il dispose permettent de proposer des raccordements partout en France.

Parce qu’il dépend de votre adresse autant que de l’offre : la distance au point de raccordement et les travaux éventuels pèsent souvent davantage que le débit. Un tarif affiché serait faux une fois sur deux — l’étude, elle, est gratuite.

Une fibre FTTH, même « pro », reste mutualisée : le débit est un maximum partagé, et l’envoi est généralement bien plus lent que la réception. Une FTTO vous réserve le débit, dans les deux sens, avec une garantie contractuelle de rétablissement. Le prix s’en ressent, la fiabilité aussi.

Non. Le réseau de notre partenaire opérateur couvre le territoire, et les collectes dont il dispose nous permettent de proposer des offres partout en France — Rennes, Paris, Toulouse, Strasbourg, Marseille et ailleurs.

Cela dépend entièrement de votre adresse et de ce qui existe déjà dans la rue : d’un délai court si le génie civil est en place, à plusieurs mois s’il faut creuser. L’étude d’éligibilité répond à cette question avant toute chose, et avant tout engagement.

Parce qu’il dépend de votre adresse autant que du débit : la distance au point de raccordement et les travaux éventuels pèsent davantage que le débit lui-même. Un tarif affiché serait faux une fois sur deux. L’étude est gratuite.

Parce que vous n’avancez rien et que vous ne portez plus la mise à jour ni le suivi des renouvellements. Nous facturons un abonnement mensuel, le plus souvent sans engagement, et nous gérons le parc à distance. Une licence achetée puis oubliée protège mal.

Antivirus et anti-spam →

Ni l’un ni l’autre dans la plupart des cas : l’installation et l’intervention se font à distance, par prise de contrôle de vos équipements. C’est aussi ce qui permet de traiter un problème ponctuel dans la foulée de l’appel.

Les deux, et dans cet ordre : notre métier premier reste l’hébergement de sites internet, mais notre métier de fond est l’informatique. C’est ce qui nous permet d’intervenir aussi bien sur un serveur que sur un client de messagerie qui ne fonctionne plus.

Non : elle permet de revenir en arrière, elle n’empêche rien. L’antivirus bloque ce qui essaie d’entrer, la sauvegarde rattrape ce qui est passé. Les deux se complètent, et face à un rançongiciel c’est la seconde qui vous rend vos données — à condition qu’elle soit hors de vos murs.

Sauvegarde distante →

Le plus souvent non. La facturation est mensuelle et s’adapte au parc : elle suit le nombre de protections déployées ou le volume sauvegardé, à la hausse comme à la baisse.

Parce que vous n’avancez rien et que vous ne portez plus la mise à jour. Le règlement d’une mensualité vous donne le droit d’utiliser le logiciel pendant un mois ; à l’échéance vous renouvelez si vous le souhaitez, et le logiciel évolue automatiquement. Vous gardez aussi votre indépendance : changer de solution ne suppose pas d’en racheter une complète.

Nos offres commencent à moins de 3 € TTC par mois pour la protection complète d’un équipement. La facturation suit le nombre de protections déployées, sans investissement initial ni engagement minimal.

Nous. Nos consoles de gestion nous donnent accès à tous les événements générés par votre antivirus, votre pare-feu et votre antispam : vous n’avez plus à vérifier si la protection est à jour. En cas d’alerte, nous vous prévenons et prenons les mesures nécessaires.

Les postes et les serveurs, oui, y compris contre le spam qui leur arrive. Pour filtrer en amont, avant que les messages n’atteignent votre serveur de messagerie, c’est notre passerelle anti-spam qu’il faut — les deux se complètent.

Passerelle anti-spam →

Non, et c’est une confusion coûteuse. L’antivirus bloque ce qui essaie d’entrer ; la sauvegarde permet de revenir en arrière quand quelque chose est passé. Face à un rançongiciel, c’est la seconde qui vous rend vos données — à condition qu’elle soit hors de vos murs.

Sauvegarde distante →

Essential si le travail se fait au navigateur et que la messagerie compte le plus. Business si vos utilisateurs ont besoin des logiciels installés sur leur poste, mais ont déjà une messagerie ailleurs. Business Premium si vous voulez les deux, plus la visioconférence.

Sur devis, selon le nombre d’utilisateurs et la répartition entre les trois formules — elles se panachent, chaque personne prenant celle qui correspond à son usage. Ce qui ne bouge pas, quel que soit le devis : l’absence d’engagement de durée, et l’assistance téléphonique avec prise en main à distance, incluses.

Nous contacter →

Vous pouvez l’associer à notre solution Kerio Connect, sur laquelle vous bénéficiez alors d’une remise. C’est souvent plus économique que de monter en gamme pour la seule messagerie.

Kerio Connect →

Sur les infrastructures de Microsoft : c’est leur service, nous le distribuons et nous vous accompagnons dessus. C’est une différence importante avec nos offres d’hébergement, où les données sont sur nos propres machines en France. Si cette localisation est un critère pour vous, dites-le nous — d’autres solutions existent.

E-mails hébergés chez nous →

Pas par le fait d’être chez Microsoft. Une boîte hébergée reste exposée à la suppression, au départ d’un collaborateur ou à un rançongiciel qui remonte depuis un poste. La sauvegarde des boîtes Microsoft 365 est une prestation distincte.

Sauvegarde distante →

Non, c’est tout le principe : ni NAS, ni licence logicielle à acheter. La solution se facture au mois, selon le volume consommé, et le logiciel est compris. Vous gardez votre capacité d’investissement pour autre chose.

Nous, à distance. Une sauvegarde dont l’agent n’est plus à jour est une sauvegarde qui finit par échouer sans que personne ne le remarque — c’est précisément ce que la prestation gérée évite.

Nous surveillons vos sauvegardes depuis nos consoles. En cas d’alerte, nous vous prévenons et prenons les mesures nécessaires. C’est la différence entre une sauvegarde installée et une sauvegarde suivie.

Oui, et c’est souvent le bon rythme. Le tarif s’adapte à la consommation : on démarre par les données les plus critiques, puis on étend au reste du parc quand cela se justifie.

Elle est votre dernier recours, et il doit tenir. Mais elle ne remplace ni un antivirus, ni des mises à jour, ni des sauvegardes testées. Restaurer se prépare avant l’incident, pas pendant.

Antivirus et antispam →

Pour récupérer un fichier effacé ce matin, il est même le plus rapide. Mais il subit ce que subissent vos locaux : incendie, dégât des eaux, vol emportent l’original et la copie. Et un rançongiciel chiffre volontiers le NAS en même temps que les postes — c’est devenu sa cible prioritaire, précisément parce qu’il sait que la sauvegarde s’y trouve.

Non : l’usage professionnel consiste à empiler, pas à choisir. Trois copies, sur deux supports différents, dont une hors site — la règle n’a pas d’équivalent plus simple, et le « hors site » est justement ce que la sauvegarde locale ne peut pas assurer.

Mensuellement, au volume réellement consommé, sans investissement initial. Cela permet de commencer par ce qui compte le plus et d’étendre ensuite, plutôt que de dimensionner un stockage complet dès le premier jour.

Sauvegarde distante →

Non. Écrire deux fois protège de la panne matérielle, pas de la suppression d’un fichier ni du chiffrement de son contenu : la redondance recopie fidèlement le dégât. Ce sont deux protections différentes, contre deux risques différents.

Elle permet de revenir en arrière ; elle n’empêche rien. Sur un serveur ou un site, elle vient après les protections qui bloquent l’attaque — pare-feu applicatif, correction des failles, détection des fichiers compromis. C’est la dernière ligne, pas la première.

Sécurisation du SI →

Non, et c’est une règle que nous tenons fermement : l’usage marketing est prohibé sur nos offres de messagerie. Une campagne partie d’un serveur de boîtes aux lettres abîme sa réputation, et donc la délivrabilité de tous les clients qui s’y trouvent. Les campagnes partent d’une infrastructure distincte, prévue pour cela.

Hébergement d’e-mails →

Une question de fréquence. En location, vous utilisez la base pour une campagne que nous routons. En vente, vous la travaillez dans la durée avec vos propres outils — ce qui devient plus économique au-delà de plusieurs campagnes par an sur la même cible.

Sur devis, et cela dépend d’abord du ciblage : la taille de la liste, les canaux retenus, et le fait qu’il s’agisse d’une campagne unique ou d’un programme dans la durée. Décrivez-nous la cible avant le budget — c’est elle qui détermine le reste.

La prospection est encadrée, et les règles diffèrent selon le canal comme selon le destinataire. Ces arbitrages relèvent de votre responsabilité, et nous vous orienterons vers un conseil juridique quand c’est nécessaire — nous ne sommes pas un cabinet d’avocats. Nous intervenons sur la partie technique et documentaire de la conformité.

Accompagnement RGPD →

Il est lu, presque toujours et presque tout de suite — c’est son avantage sur tous les autres canaux. C’est aussi ce qui impose d’en user avec parcimonie : un message court, une raison claire d’écrire, et une cible étroite. Il sert bien en relance ou en information, moins en prospection à froid.

Le principe est le même, et nous ne prétendrons pas le contraire : une plateforme qui reçoit vos envois et les route en surveillant la délivrabilité. La différence tient à l’infrastructure et à l’interlocuteur — un routage que nous exploitons nous-mêmes, des données qui restent en France, et quelqu’un à qui parler quand un envoi ne part pas.

Oui, et c’est un usage fréquent. Beaucoup d’applications n’ont aucune campagne à envoyer mais ne peuvent pas se permettre de perdre une réinitialisation de mot de passe. C’est exactement le cas où l’on ne veut pas router depuis le serveur de l’application.

Cela dépend de la façon dont elle envoie aujourd’hui. Une application qui passe déjà par un serveur SMTP change de paramètres, rien de plus. Une intégration plus fine se discute selon ce que vous voulez suivre — ouvertures, échecs, désinscriptions.

Elle reste où elle est, et c’est préférable. Les boîtes de l’entreprise et le routage de campagne sont deux infrastructures distinctes chez nous, délibérément : mélanger les deux abîmerait la réputation des serveurs qui portent votre courrier quotidien.

E-mails professionnels →

Une liste de destinataires est un fichier de données personnelles : il lui faut une base légale, une durée de conservation et un moyen de se désinscrire qui fonctionne. L’outil ne dispense pas de cette réflexion, il la rend seulement applicable.

Accompagnement RGPD →

Oui, c’est le point de départ du projet. Le site est livré avec une interface d’administration et nous vous montrons comment vous en servir. Modifier un prix ou remplacer le plat du jour prend moins d’une minute, depuis un ordinateur comme depuis un téléphone.

Les deux ne font pas le même travail. La fiche Google vous rend visible sur la carte ; le site est le seul endroit dont vous maîtrisez le contenu, la carte complète et les photos. Ils se renforcent l’un l’autre : une fiche renvoie vers un site, et un site cohérent conforte la fiche.

Selon le volume, un simple formulaire de commande suffit, ou bien une vraie boutique en ligne avec paiement. Nous en discutons avant de choisir : une boutique demande de la gestion au quotidien, elle n’a d’intérêt que si les commandes suivent.

Une présentation complète — carte, horaires, accès, photos, formulaire — démarre à 250 € HT en création. Il existe aussi une formule de location à 9 € HT par mois, engagement de 12 mois, nom de domaine en sus, qui comprend le site, son hébergement et le support.

C’est la règle plutôt que l’exception, et c’est pris en compte dans la conception : un site d’artisan doit rester juste même s’il n’est pas touché pendant six mois. Publier une réalisation se résume ensuite à envoyer trois photos et une phrase — deux minutes depuis un téléphone. Si vous préférez ne rien faire du tout, nous pouvons nous en charger.

Oui, dans l’immense majorité des cas. Un chantier photographié en lumière du jour, cadré droit, fait le travail. Le site redimensionne et compresse automatiquement à la publication, vous n’avez rien à préparer.

Le bouche-à-oreille n’a pas disparu, il transite juste par internet : on vous recommande, puis on vérifie. Un site est l’endroit où cette vérification se termine bien — sinon elle se termine sur un annuaire qui ne vous appartient pas.

Une présentation d’activité avec galerie et formulaire démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Le délai dépend surtout de la vitesse à laquelle vous nous fournissez photos et textes : c’est presque toujours ce qui commande le calendrier.

Rien ne vous y oblige, mais l’expérience va dans un sens : une visiteuse qui ne trouve pas de prix ouvre l’onglet suivant. Afficher une fourchette ou un tarif de départ suffit souvent, et vous évite les demandes hors budget.

Oui. La boutique peut être configurée en retrait à l’institut uniquement : la cliente paie en ligne et vient chercher son produit. C’est le mode le plus simple à démarrer, et l’expédition peut s’ajouter plus tard.

Nous le branchons plutôt que de le remplacer. Le site renvoie vers votre outil, ou l’intègre dans une page selon ce qu’il permet. Changer d’outil de planning est une décision de gestion, pas une décision de site internet.

Une présentation avec carte des soins, photos et formulaire démarre à 250 € HT, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. L’ajout d’une boutique en ligne fait l’objet d’un devis : le travail dépend du nombre de références et des modes de livraison.

C’est le point de départ du projet. Le planning est une donnée que vous seul connaissez en temps réel : il serait absurde qu’il faille nous écrire pour l’ajuster. L’interface est faite pour être utilisée depuis un téléphone, entre deux cours.

Les deux servent des publics différents. L’application est pour ceux qui sont déjà inscrits ; le site est pour ceux qui hésitent encore et ne téléchargeront rien avant d’être convaincus. Le site peut renvoyer vers l’application une fois l’inscription faite.

Oui, avec paiement en ligne et, si besoin, prélèvement mensuel. C’est un projet à part entière — il touche à votre gestion, pas seulement à votre vitrine — et il fait l’objet d’un devis. Beaucoup de clubs démarrent avec la demande d’essai, et ajoutent la vente ensuite.

Un site avec planning, tarifs, actualités et formulaire démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. La vente d’abonnements en ligne se chiffre séparément.

Oui, et elles sont intégrées au site plutôt qu’ajoutées après coup : message sanitaire obligatoire, vérification de la majorité de l’acheteur, mentions sur l’abus d’alcool, conditions de vente et de livraison. Nous les mettons en place, mais la responsabilité éditoriale reste la vôtre — c’est vous qui connaissez vos obligations d’exploitant.

Oui. Le site peut présenter les cuvées et les tarifs sans boutique, avec retrait et paiement sur place. Beaucoup de domaines commencent ainsi et ajoutent la vente en ligne une fois la logistique d’expédition réglée.

Non, mais le peu doit être vrai. Un journal du vignoble à quatre entrées par an — taille, floraison, vendanges, mise — suffit largement et vaut mieux qu’un blog abandonné en mars. Le site est conçu pour rester juste même sans publication.

Une présentation avec cuvées, actualités et informations d’accueil démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. La boutique en ligne, avec ses contraintes de port et de conditionnement, fait l’objet d’un devis.

Oui, c’est l’usage plutôt que l’exception. Un catalogue tient dans un export — tableur, base ou flux ONIX selon l’outil de départ — que nous reprenons pour créer les fiches. La ressaisie manuelle n’est envisagée que pour les très petits catalogues, où l’automatiser coûterait plus cher.

Elles sont conservées, ou redirigées une à une vers leur nouvelle adresse. C’est un point que nous traitons systématiquement lors d’une refonte : une fiche d’ouvrage citée dans un article de presse ou un catalogue de libraire doit continuer de fonctionner.

La boutique applique le prix que vous fixez, sans mécanisme de remise automatique. Les règles de remise et de frais de port relèvent de la loi Lang et de votre politique commerciale : nous configurons ce que vous décidez, nous ne le décidons pas à votre place.

Un catalogue consultable sans vente démarre à 250 € HT en création. Un site avec boutique, reprise de catalogue et espace presse fait l’objet d’un devis : le travail dépend du nombre de titres et de la qualité des données de départ.

Oui, si vous le souhaitez. Chaque professionnel dispose alors d’un accès limité à sa fiche : il corrige ses horaires ou son téléphone sans pouvoir toucher au reste. C’est un choix d’organisation autant que technique — certains réseaux préfèrent garder la main pour tenir la cohérence de l’annuaire.

Oui, à partir d’un export : tableur, base de données ou site à reprendre. Nous importons les fiches, vous les relisez, et la maintenance passe ensuite en manuel. Les adresses de pages existantes peuvent être conservées ou redirigées une à une.

Pas toujours. Une carte est utile quand la répartition géographique est le sujet, et coûteuse quand elle ne l’est pas — elle alourdit la page et, selon la solution retenue, pose des questions de données personnelles. Une recherche par code postal suffit dans beaucoup de cas. Nous en discutons avant de la mettre.

Un annuaire relève du développement, pas du site vitrine : il fait l’objet d’un devis. Le travail dépend du nombre de fiches, du mode de mise à jour retenu et de l’existence ou non d’un annuaire à reprendre. Une mission de conseil en amont se facture à partir de 1 000 € par jour, dégressif selon la durée.

La vente à distance d’équipements optiques est possible en France, mais elle est encadrée : mentions obligatoires, informations sur la délivrance, et l’ordonnance reste nécessaire pour un équipement correcteur. C’est un projet à part entière, très différent d’une vitrine. Nous pouvons le construire, à condition de partir de vos obligations professionnelles — c’est vous qui les connaissez, pas nous.

Décrire vos prestations, expliquer un examen, informer sur l’entretien des lentilles : oui. En revanche la publicité relative aux dispositifs médicaux est réglementée, et les promesses de résultat sont à proscrire. Nous rédigeons dans un registre informatif et nous vous laissons valider : la responsabilité éditoriale est la vôtre.

Le site de l’enseigne parle de l’enseigne ; il ne dit ni qui vous êtes, ni ce que votre magasin fait de particulier. Selon votre contrat de franchise, un site local peut être autorisé, encadré ou interdit — c’est la première chose à vérifier avant d’engager quoi que ce soit.

Une présentation complète — marques, services, prise en charge, rendez-vous, accès — démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. La vente en ligne fait l’objet d’un devis séparé.

Oui. La publicité et la communication des avocats sont autorisées depuis longtemps, à condition de rester dignes, loyales et exactes, sans démarchage ni sollicitation personnalisée. Ce qui reste proscrit est identifiable : comparaison avec des confrères, témoignages de clients, promesses de résultat, mention de dossiers identifiables. Nous construisons dans ce cadre — et vous validez, car la responsabilité déontologique reste la vôtre.

Non, et c’est le point sur lequel les prestataires généralistes se trompent le plus souvent. Le secret professionnel et les règles de communication l’interdisent en pratique. Nous ne mettons donc jamais de bloc d’avis sur un site de cabinet, quand bien même l’outil serait disponible.

C’est la forme la plus efficace pour un cabinet, à condition de la tenir. Un commentaire d’arrêt par trimestre vaut mieux que dix articles génériques recopiés. Si vous n’avez pas le temps d’écrire, mieux vaut un site sans blog qu’un blog arrêté depuis deux ans — l’un est neutre, l’autre est un signal négatif.

Un site de présentation — domaines, avocats, honoraires, contact — démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Un espace client sécurisé pour l’échange de pièces relève du développement et fait l’objet d’un devis.

Elle est encadrée par le règlement national des notaires : la communication est autorisée si elle reste digne, loyale et respectueuse du secret professionnel, sans démarchage ni comparaison. Un site informatif entre pleinement dans ce cadre. Nous rédigeons dans ce registre, et l’office valide chaque page avant publication.

Oui, c’est même la condition pour que le module serve à quelque chose. Une annonce se crée et se retire depuis l’interface d’administration en quelques minutes. Si vous alimentez déjà un portail, une reprise automatique du flux peut être étudiée pour éviter la double saisie.

Le moins possible. Un formulaire ne doit collecter que ce dont l’office a besoin pour rappeler, avec une information claire sur l’usage et la durée de conservation. Nous construisons sans traceur publicitaire et hébergeons en France, sur notre propre matériel — pour une étude tenue au secret, cela simplifie beaucoup la question.

Un site de présentation avec domaines, équipe et contact démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Le module d’annonces immobilières s’ajoute et fait l’objet d’un devis selon le volume de biens et la reprise éventuelle d’un flux existant.

Oui. Depuis 2020, les praticiens peuvent communiquer sur leur activité par voie électronique, à condition que l’information soit loyale, honnête, scientifiquement étayée et sans caractère promotionnel ou comparatif. Un site informatif est donc pleinement admis. C’est le ton qui change tout : on décrit, on n’argumente pas.

C’est le point le plus sensible et nous le déconseillons. Une comparaison avant/après relève de la promotion d’un résultat, ce que le code de déontologie n’admet pas, et elle pose en outre une question de données de santé du patient. Nous n’en mettons pas, sauf instruction écrite de votre part après vérification auprès de votre conseil départemental.

Nous n’installons pas de module d’avis sur un site de cabinet. Solliciter et afficher des témoignages de patients entre dans le registre promotionnel et touche au secret médical. Un site de santé se juge sur la qualité de son information, pas sur une note.

Un site informatif — praticiens, soins, informations pratiques, urgences, honoraires — démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Nous hébergeons sur notre propre infrastructure en France, ce qui compte quand le site porte des données de patients, même indirectement.

Oui. Le code de déontologie des masseurs-kinésithérapeutes autorise la communication au public, dès lors qu’elle est loyale, honnête, scientifiquement étayée, et qu’elle ne présente aucun caractère promotionnel ou comparatif. Un site d’information sur le cabinet et ses techniques entre dans ce cadre.

Vous pouvez indiquer les techniques que vous pratiquez et vos formations. Ce qui n’est pas admis, c’est de laisser entendre qu’elles seraient supérieures à d’autres ou qu’elles garantissent un résultat. La différence est mince à l’écrit : c’est pour cela que nous rédigeons avec vous et que vous validez chaque page.

Cela dépend de votre organisation. Si vous utilisez déjà une plateforme, le site y renvoie — votre planning ne doit pas dépendre du site. Si votre patientèle est stable et que le rendez-vous se prend en fin de séance, un formulaire suffit, voire un simple numéro bien visible.

Un site informatif complet démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Il est hébergé sur notre propre infrastructure à Saint-Herblain, en France.

Sur les forfaits, oui, et c’est ce qui distingue le plus un site de garage utile d’un site de garage décoratif. Un prix de départ pour une révision ou une vidange n’engage pas sur un devis complexe, mais il répond à la question que tout le monde se pose et que personne n’ose poser au téléphone. Pour les réparations, une demande de devis reste la bonne réponse.

Oui, c’est prévu ainsi : un véhicule se publie et se retire en quelques minutes, depuis un ordinateur ou un téléphone. Si vous diffusez déjà sur un portail d’annonces, une reprise du flux peut être étudiée pour éviter la double saisie.

C’est la première chose à vérifier dans votre contrat. Certaines enseignes fournissent un site local, d’autres l’encadrent, d’autres l’interdisent. Quand un site local est possible, il vaut presque toujours mieux que la page générique du réseau : il porte vos horaires, vos tarifs et votre atelier.

Un site avec prestations, forfaits, accès et demande de rendez-vous démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Le module de véhicules d’occasion s’ajoute et fait l’objet d’un devis.

C’est le mode normal de fonctionnement, et la première chose que nous vérifions. La plupart des logiciels du marché exportent un flux d’annonces standard. Le site le consomme et se met à jour tout seul : plus de bien fantôme resté en ligne après la vente, plus de saisie en double. Si votre logiciel n’expose rien, nous regardons ce qu’il permet avant de vous promettre quoi que ce soit.

Les portails apportent des acquéreurs, votre site apporte des vendeurs. Ce ne sont pas les mêmes personnes ni la même économie : un acquéreur cherche un bien et le trouvera partout, un vendeur cherche une agence et se renseigne sur elle. C’est pour capter le second qu’un site d’agence est rentable.

Utile pour capter un contact, risquée si elle affiche un prix. Une estimation algorithmique fausse vous met en difficulté au premier rendez-vous. Nous privilégions un formulaire qui recueille les caractéristiques du bien et débouche sur un rappel — vous gardez la main sur le chiffre.

Un site de présentation démarre à 250 € HT en création. Un site d’agence avec reprise de flux d’annonces, recherche multicritère et estimation relève du développement et fait l’objet d’un devis : le travail dépend surtout de votre logiciel de transaction et de la qualité de son flux.

Parce qu’on y publie les fichiers tels que le photographe les livre — des JPEG de plusieurs mégaoctets, parfois vingt sur une même page. Sur mobile, la page ne s’affiche jamais entièrement. Nous traitons le problème à la source : les images sont converties et déclinées en plusieurs tailles à la publication, et le navigateur ne charge que ce dont il a besoin. Vous continuez à envoyer les fichiers d’origine.

C’est un choix d’agence, pas une règle. Le budget aide un maître d’ouvrage à savoir s’il est dans la bonne fourchette, ce qui vous évite des rendez-vous inutiles ; il peut en revanche poser problème vis-à-vis de certains clients. Beaucoup d’agences publient la surface et le programme, et gardent le budget pour le premier rendez-vous.

Non, un dossier de candidature reste un dossier. Mais un portfolio bien tenu, classé par programme, avec les surfaces et les maîtres d’ouvrage, rend la constitution de ces dossiers nettement plus rapide — les références y sont déjà rédigées.

Un portfolio avec fiches de projets, présentation de l’agence et contact démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Une conception graphique entièrement sur mesure, fréquente dans ce métier, fait l’objet d’un devis.

Les réseaux servent à être découvert, le site à être choisi. Ce ne sont pas les mêmes moments. Et il y a une différence de fond : un compte peut être suspendu, son algorithme peut cesser de vous montrer, et vous ne possédez ni l’audience ni les images une fois publiées. Votre site vous appartient, y compris ses adresses, qui restent citables des années.

Par des galeries privées hébergées sur votre propre site : une galerie par client, protégée par mot de passe, avec téléchargement des fichiers. C’est plus soigné qu’un lien de transfert, cela reste chez vous, et cela évite les services gratuits dont on ne sait ni où sont les fichiers, ni combien de temps ils y restent.

Protégées, non — toute image affichée peut être capturée, et prétendre le contraire serait malhonnête. On peut en revanche décourager la reprise et documenter vos droits : filigrane discret si vous le souhaitez, définitions d’affichage limitées, crédits et conditions d’utilisation clairement écrites. C’est ce dernier point qui compte réellement en cas de litige.

Un portfolio avec séries, prestations, tarifs et contact démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Les galeries privées de livraison s’ajoutent et font l’objet d’un devis, selon le volume de séances et l’espace de stockage nécessaire.

Les deux ne jouent pas le même rôle. La plateforme prend les rendez-vous de gens qui vous connaissent déjà, et vous prélève une commission sur ceux qu’elle vous apporte. Le site est votre adresse à vous : il présente vos tarifs, votre équipe et votre travail, et renvoie vers la plateforme pour la réservation. C’est le seul canal dont personne ne peut vous exclure ni faire monter le prix.

Pour se faire découvrir, les réseaux sont efficaces. Pour être choisi, moins : on n’y trouve ni les tarifs, ni les horaires, ni l’adresse sans fouiller. Et une publication vieille de six mois est introuvable. Un site rassemble ce qui doit rester consultable ; les réseaux gardent ce qui est fait pour passer.

L’affichage des tarifs est obligatoire en salon, et il l’est aussi sur un site qui présente des prestations. Au-delà de l’obligation, c’est votre meilleur outil de tri : un client qui connaît le prix du balayage avant de venir ne le découvre pas en caisse.

Un site avec prestations, tarifs, équipe, photos, horaires et accès démarre à 250 € HT en création, ou 9 € HT par mois en location, engagement de 12 mois, nom de domaine en sus. Le branchement d’une plateforme de rendez-vous est inclus dans la construction.