Hébergement et exploitation
Nous mettons en ligne, sécurisons, surveillons et faisons évoluer les sites et les applications que nous développons ou que nous reprenons.
Un produit en ligne demande un serveur tenu à jour, des sauvegardes que l'on sait restaurer, une surveillance qui prévient avant les utilisateurs et quelqu'un pour traiter les demandes. Nous exploitons de cette façon les réalisations de notre portfolio, sur une vingtaine de serveurs (octobre 2026). Nous proposons la même pratique à nos clients, dans un cadre écrit. Nous ne possédons pas de centre de données : nous administrons des serveurs loués chez des hébergeurs.
Un serveur par projet
Chaque projet a son serveur, sa base de données et ses accès. Un incident ou une charge inhabituelle sur un produit ne touche pas les autres, et un projet peut être transféré sans démêler une infrastructure partagée. La chaîne est la même partout : Cloudflare devant le domaine (DNS, certificat, filtrage), Nginx ou Caddy sur le serveur, l'application Next.js lancée par PM2 ou systemd, et Supabase auto-hébergé dans Docker pour la base, l'authentification et le stockage. Héberger Supabase nous-mêmes donne le contrôle des données et de leur emplacement, sans dépendre d'une offre en nuage. Les comptes d'administration et de développement sont séparés, et le compte applicatif n'est pas root.
Des mises en ligne scriptées, avec retour arrière
Un déploiement suit un script propre au projet. L'application est construite hors du dossier servi, des contrôles passent (types, contenu, sécurité de base), un verrou empêche deux déploiements simultanés, puis la bascule a lieu et un test de santé vérifie le résultat. En cas d'échec, la version précédente est rétablie. Sur Miapoda, la bascule se fait entre deux versions qui tournent côte à côte. Le code est poussé dans un dépôt Git avant toute mise en service. Les migrations suivent les mêmes principes : sauvegarde datée avant tout déplacement, simulation avant application, vérification après chaque bascule. Un changement qui touche le paiement, l'authentification ou les données reçoit une recette plus poussée qu'une correction de texte.
Sécurité, sauvegardes et supervision
Le durcissement suit une liste en niveaux. Le premier est bloquant avant la mise en production : accès SSH par clé seulement, pare-feu, blocage des tentatives répétées, ports exposés par Docker refermés. Le deuxième est appliqué dans les 30 jours : audit du système, détection d'intrusion, journalisation. Les sauvegardes de base sont quotidiennes, envoyées hors du serveur, et nous testons une restauration avant de considérer qu'une sauvegarde existe. La supervision ne s'arrête pas à la page d'accueil : elle contrôle les interfaces, les API, les tâches planifiées et les services externes dont dépend le produit, et un rapport quotidien résume l'état réel de chaque service.
Ce que nous ne promettons pas
Nous ne publions ni taux de disponibilité, ni délai de rétablissement garanti, ni astreinte jour et nuit. Ces engagements se financent et se vérifient, et nous préférons ne pas les afficher que les afficher sans preuve. Le cadre de chaque prise en charge est écrit avec le client : heures de couverture, canal de demande, niveaux de priorité, ce qui est inclus et ce qui ne l'est pas. Une prise en charge commence par un inventaire et par une sauvegarde restaurée, pas par une promesse sur un système encore inconnu. Nous ne délivrons pas de certification de sécurité et nous ne garantissons pas une conformité réglementaire générale.
Les services
Chaque service a sa page : ce que vous obtenez, comment nous procédons, et la réalisation qui le montre.
Hébergement géré
Un serveur dédié à votre projet, installé, sécurisé et tenu par l'équipe qui connaît votre application.
Sécurité et durcissement des serveurs
Nous fermons ce qui n'a pas à être ouvert sur un serveur Linux, par une liste de contrôle en niveaux, avec un rapport de ce qui a été fait.
Supervision et sauvegardes
Savoir que le service fonctionne réellement, et pouvoir le restaurer s'il ne fonctionne plus.
Maintenance et évolution
Un cadre écrit pour corriger, mettre à jour et faire évoluer votre site ou votre application après la mise en ligne.
Pour qui
Clients dont nous développons le produit
La mise en ligne et l'exploitation prolongent le développement : la même équipe connaît le code, la base et le serveur.
Organisations qui reprennent la main sur un site existant
Votre site tourne sur un serveur que plus personne ne suit. Nous l'inventorions, le sécurisons et le documentons avant de le prendre en charge.
Projets soumis à une contrainte de localisation des données
Un serveur situé au Canada est une option possible quand vos obligations, par exemple la Loi 25 au Québec, ou vos clients le demandent.
Équipes sans administrateur système
Vous avez des développeurs, pas d'exploitant. Nous tenons le serveur, les sauvegardes et la surveillance, et votre équipe garde le code.
Nos règles de travail
Elles s'appliquent à chaque mission, quel que soit le service.
Isoler
Un serveur, une base et des accès par projet. Les risques et les coûts d'un produit restent les siens.
Vérifier par l'effet
Une sauvegarde compte quand elle a été restaurée. Une alerte compte quand elle arrive à quelqu'un qui sait quoi faire.
Donner le moins de droits possible
Comptes séparés pour l'administration, le développement et les automatisations. Chaque automatisation écrit sous un rôle limité à ce qu'elle doit faire.
Garder les secrets hors du code
Les clés vivent dans des fichiers d'environnement protégés. Des garde-fous bloquent l'envoi d'un secret dans un dépôt ou une sauvegarde.
Documenter pour pouvoir transmettre
Chaque service a sa fiche : domaine, environnements, dépôts, dépendances, tâches planifiées, contacts. Elle sert à l'exploitation et à la réversibilité.
Des réalisations qui le montrent
Danzina
Annuaire mondial de la danse et logiciel de gestion pour les écoles, en trois langues.
EraCoach
Place de marché trilingue de coachs certifiés, avec réservation et paiement en ligne.
Bidanga
Agrégateur d'appels d'offres publics africains, normalisés et traduits en cinq langues.
imonga
Portail immobilier panafricain : annonces, programmes neufs, annuaire et gérance locative.
Fontshi Notaire
Site bilingue et portail client d'une étude notariale de Montréal
Amorcia
Plateforme bilingue qui oriente les innovateurs africains vers les financements ouverts
Questions fréquentes
Où sont hébergées les données ?
Sur un serveur loué chez un hébergeur, choisi avec vous selon le projet. La plupart de nos serveurs sont en Europe. Un serveur situé au Canada est possible quand le projet le demande. La région réelle figure dans la fiche de service du projet.
Garantissez-vous un taux de disponibilité ou une astreinte 24 heures sur 24 ?
Non. Nous ne publions pas d'engagement de disponibilité ni d'astreinte permanente. Les heures de couverture, les délais de prise en charge et les exclusions sont fixés avec vous dans le contrat, en fonction de l'importance du service et du budget.
Puis-je partir avec mon site et mes données ?
Oui. La réversibilité est décrite avant le démarrage : export des données, des contenus et des médias, transfert des comptes et des domaines selon les droits, documentation des dépendances, suppression de nos accès. Comme chaque projet a son propre serveur, le transfert ne dépend d'aucun autre client.
Hébergez-vous un site que vous n'avez pas développé ?
Oui, après une reprise. Nous inventorions le service, contrôlons les accès, faisons une sauvegarde et une restauration de référence, puis corrigeons ce qui bloque. Nos engagements commencent une fois ces prérequis remplis.
Qui est titulaire des comptes d'hébergement et du nom de domaine ?
Cela se décide projet par projet et s'écrit. La fiche de service nomme l'opérateur, le titulaire des comptes, le payeur et le propriétaire des données. Nous recommandons que le nom de domaine reste au nom du client.
Quel problème voulez-vous régler ?
Décrivez votre activité, votre besoin et les personnes concernées. Nous préparons un premier échange à partir de là.