Questions fréquentes

MS WebX est une société informatique. Nous concevons des sites et des plateformes web, des applications natives iOS et Android, et nous y intégrons de l'IA — avec le travail de référencement qui rend le résultat visible. Nous exploitons aussi nos propres produits sur la plateforme que nous utilisons pour nos clients : la base tourne donc en production avant que quiconque en dépende.

Les deux, volontairement. Ce que nous proposons tourne d'abord dans nos propres produits : le système de pages multilingue, la couche API, les outils d'administration, l'analytique. Aucun projet client ne démarre sur une base non éprouvée, et si quelque chose casse dans le socle, nous le voyons avant le client.

De trois façons, toutes indépendantes de ce que nous écrivons ici. Les mentions légales de ce site portent les informations officielles de la société. Nos produits sont publics et utilisables sans nous contacter. Et la page de contact aboutit chez les personnes qui écrivent le code, sans centre d'appel intermédiaire.

Vous décrivez l'objectif, pas la solution technique. Nous posons des questions jusqu'à ce que le périmètre soit réellement clair, puis nous l'écrivons avant de construire quoi que ce soit. Si votre demande nous semble être le mauvais chemin vers votre but, nous le disons avant que vous payiez : cette discussion coûte moins cher que la refonte qu'elle évite.

Par petites étapes visibles. Le travail arrive sur un environnement de préproduction que vous pouvez ouvrir dans votre navigateur quand vous le souhaitez, et ne passe en ligne que sur votre accord. Personne ne découvre le produit fini à la fin du projet : à ce moment-là, toute modification coûte cher.

Ce que nous construisons est fait pour être maintenu : mises à jour des dépendances, supervision, évolutions quand votre activité évolue. Que nous continuions ou que votre équipe reprenne se décide pendant le projet, pas après coup. Rien n'est conçu pour que nous soyons les seuls à pouvoir y toucher.

Nous lisons d'abord le code existant, puis nous disons franchement si le poursuivre ou le remplacer coûte moins cher sur la durée de vie du système. Les deux réponses arrivent : un code hérité est souvent très correct, simplement mal documenté. Nous ne recommandons pas une refonte par réflexe, car c'est la chose la plus chère qu'on puisse vous vendre.

PHP côté serveur, TypeScript côté navigateur, Flutter pour iOS et Android, MariaDB pour les données, nginx et FrankenPHP pour la diffusion. Des technologies actuelles et largement connues, volontairement, pour que n'importe qui puisse reprendre après nous. La qualité est tenue par des machines, pas par de bonnes intentions : l'analyse statique tourne à son niveau le plus strict sans liste d'exceptions, avec plus de deux cents règles maison qui rejettent le code dès qu'il dérive.

Une base de code avec un noyau commun et une fine couche par marque au-dessus. Chaque marque a son design, son contenu, sa base de données et son domaine, tandis que les correctifs de sécurité, le travail de performance et les nouvelles fonctions du noyau arrivent partout en même temps, sans recopie manuelle site par site. Ajouter une marque relève de la configuration et du contenu, pas d'un fork.

Oui, et plus strictement que ce que cette phrase signifie d'habitude. L'API est définie une seule fois en PHP, et le client TypeScript du web comme le client Dart de l'application en sont générés. Aucun n'est écrit à la main : le linter refuse un type d'API écrit manuellement. L'application ne peut donc pas se désynchroniser en silence — un écart casse la compilation, pas la production.

Réelles. Chaque page existe comme un enregistrement distinct par langue, avec son texte et son URL : cette FAQ se trouve à /frequently-asked-questions en anglais et à /de/haeufig-gestellte-fragen en allemand, et non derrière un paramètre de traduction. Chaque langue peut donc être rédigée comme on cherche réellement sur ce marché, et corrigée sans toucher aux dix-sept autres.

C'est précisément sa raison d'être. Chaque marque a sa base de données, son domaine et son contenu : une marque ne peut pas lire les données d'une autre, et une erreur de contenu chez l'une n'apparaît pas chez l'autre. Ce qui est partagé, c'est le moteur : le routage, la couche API, les outils d'administration et le travail de sécurité.

Cannabivo est en ligne : un moteur de recherche de clubs sociaux, où les visiteurs trouvent et comparent les clubs par localisation et où chaque club gère sa propre fiche. Steel est une référence d'équivalences de matériaux destinée au bureau d'études et aux achats ; elle est en développement et pas encore ouverte au public. Les deux tournent sur la plateforme décrite dans cette rubrique.

À vous. Nous les traitons pour faire fonctionner le service commandé, et pour rien d'autre. Elles ne sont pas mélangées à celles d'un autre client, ni vendues, ni utilisées pour cibler vos utilisateurs avec de la publicité. Si la collaboration s'arrête, vous repartez avec vos données.

Les connexions passent en HTTP/3 et le domaine figure sur la liste HSTS préchargée des navigateurs : le navigateur refuse donc toute communication non chiffrée dès la toute première visite, avant qu'une redirection puisse être interceptée. L'échange de clés est post-quantique — X25519 combiné à ML-KEM-768 — choisi pour qu'un trafic capté aujourd'hui résiste encore le jour où un ordinateur quantique pourra s'y attaquer.

Jamais dans le code source — et c'est la compilation qui l'impose, pas la discipline : un code contenant un secret en dur est rejeté avant de pouvoir être fusionné. Les secrets sont chiffrés dans un magasin de configuration et déchiffrés à l'exécution uniquement là où ils servent, si bien que changer une clé est une modification à un seul endroit, pas une chasse dans tout le code.

Oui. Les événements applicatifs, les erreurs et les actions d'administration sont écrits en base de données plutôt que dans des fichiers texte éparpillés sur des serveurs, donc ils sont réellement consultables. Les modifications d'administration enregistrent qui a agi, ce qui a changé et quand. À « qui a modifié ce prix le mois dernier », il existe une réponse, pas une supposition.

Les cookies non essentiels ne sont posés qu'après accord du visiteur, le choix est enregistré, et chaque site que nous construisons propose une page pour le modifier ou le retirer ensuite. Refuser tient en un clic, pas en une chasse dans un menu de réglages — et qui refuse obtient quand même un site qui fonctionne.

Un modèle qui accomplit une tâche précise dans votre produit et bat la solution alternative de façon mesurable : trier les messages entrants, rédiger des textes qu'une personne valide ensuite, faire comprendre à la recherche ce que quelqu'un voulait dire plutôt que ce qu'il a tapé. Ce n'est pas une bulle de chat collée sur un site fini. La bonne question n'est jamais « peut-on ajouter de l'IA », mais « quelle tâche répétitive vous coûte du temps aujourd'hui ».

Dans le contenu. Nos textes multilingues sont produits et tenus à jour avec l'aide de modèles, puis relus langue par langue avant publication — jamais publiés directement en sortie de modèle. C'est aussi pourquoi nous parlons d'IA avec prudence : nous savons par expérience où le résultat est solide et où il faut encore une personne.

Avant toute construction, nous indiquons par écrit quel prestataire traite quelles données et ce qui est conservé. Si cette réponse ne vous convient pas, la fonctionnalité est conçue autrement ou pas du tout. Aucune donnée ne quitte votre système d'une manière que vous n'avez pas acceptée — et « on ne savait pas que c'était envoyé » n'est pas un résultat que nous acceptons de produire.