La page de confirmation s'affiche, mais le formulaire n'a atteint ni la boîte de réception ni l'adaptateur CRM. Le visiteur croit avoir demandé une intervention. L'agence voit une interface propre. Le plombier découvre le défaut quand personne ne peut retrouver la demande fictive dans les journaux.
Ce type d'écart sépare la conception visuelle du développement. FR-163 décide ce que l'écran doit montrer et comment les états sont compris. FR-164 vérifie ce qui se passe réellement entre le navigateur, le serveur, le CMS, le routage d'appel, les intégrations et les environnements de publication.
Le comparatif s'appuie sur un dossier de relève fictif pour un atelier imaginaire nommé Atelier Canal Test. Le laboratoire contient les références PLB-URGENCE, PLB-RDV et PLB-ZONE, des fiches de contenu vides, deux versions d'artefact, un formulaire local, un routeur d'appel sans numéro et un incident simulé. Rien n'est mis en ligne.
Six prestataires publient soit une offre de développement web à plusieurs couches, soit une page destinée aux plombiers qui dépasse la seule maquette. Leur site officiel permet de préparer des questions. Il ne prouve pas la qualité du code, la sécurité, la maîtrise du français, la connaissance du marché français ou la capacité à livrer le dossier décrit.
La meilleure agence n'est donc pas celle qui montre la plus belle page d'accueil. C'est celle dont la proposition transforme dépôt, environnements, CMS, formulaires, dépendances, releases, alertes et sortie en objets vérifiables dont l'entreprise reste propriétaire.
theStacc édite et publie FR-164. Les appels à l'action de cette page font la promotion des logiciels theStacc, mais theStacc ne figure pas dans le classement et ne vend pas la prestation de développement web comparée ici. Aucun prestataire n'a payé pour être inclus ou positionné. L'observation du 31 août 2026 porte sur onze URL officielles directement accessibles. Les sources prestataires sont celles de DynamoLogic, Netguru, Vention, ScienceSoft, Grow Nearby et Thrive Internet Marketing Agency. Les sources de contrôle proviennent de GitHub Docs, WordPress.org, OWASP, la CNIL et Google Search Central. Une page de prestataire prouve uniquement le périmètre que cette entreprise publie sur elle-même. Nous n'avons engagé aucune agence, demandé aucun devis, consulté aucun contrat, créé aucune entreprise de plomberie, ouvert aucun dépôt privé, lancé aucun build, relié aucun CMS, formulaire, calendrier, CRM, outil d'appel ou outil de mesure, ajouté aucune clé, déployé aucune release, exécuté aucun test de sécurité sur un système réel et traité aucune donnée personnelle. Les prix, forfaits, délais, clients, références, notes, récompenses, mesures de performance, disponibilités, appels, rendez-vous, demandes, chantiers, classements, conversions, revenus et promesses de résultat ont été exclus. Le dossier de relève est entièrement fictif. Il utilise des identifiants inventés, des fixtures sans personne, des variables sans valeur et des adaptateurs locaux. Il ne contient ni entreprise réelle, ni adresse, ni numéro, ni client, ni urgence, ni chantier, ni paiement, ni identifiant secret. Ce guide ne constitue pas un audit de sécurité, un avis juridique, une validation RGPD, une certification d'accessibilité ni un conseil professionnel de plomberie. Une organisation réelle doit faire examiner les données, le consentement, la sécurité, les licences, l'accessibilité, l'hébergement, les contrats et la mise en production par les responsables compétents. FR-163 conserve la recherche utilisateur, les parcours, les wireframes, l'identité visuelle, les composants d'interface et les validations de conception. FR-164 reçoit un lot visuel nommé et traite seulement l'architecture, le code, les contenus structurés, les intégrations, les tests, le déploiement, la surveillance, les incidents et la sortie. FR-161 et FR-162 conservent les réseaux sociaux et le marketing digital. FR-164 reste needs_human_review faute de responsable technique nommé, de revue sécurité et données, de vérification métier plomberie, de relecture française indépendante et de propriétaire de maintenance.
La réponse courte
DynamoLogic ouvre cette sélection grâce à une page plomberie qui associe développement, WordPress, PHP et Laravel. Netguru, Vention et ScienceSoft publient des chaînes techniques plus larges, mais sans spécialisation plomberie démontrée. Grow Nearby et Thrive proposent d'autres périmètres sectoriels. Le choix final doit passer par le même exercice de build, panne, rollback, export et révocation.
- DynamoLogic: Une entreprise de plomberie qui veut un point de départ sectoriel tout en imposant un dépôt client, des contrats d'intégration et une procédure de reprise
- Netguru: Un site ou produit plomberie comportant plusieurs intégrations et nécessitant une équipe d'ingénierie au-delà d'une implémentation CMS standard
- Vention: Un acheteur disposant d'une direction technique capable de sélectionner entre projet, équipe dédiée et renfort tout en gardant les actifs
- ScienceSoft: Un projet nécessitant architecture, backend, intégrations et maintenance, avec une équipe cliente capable d'apporter le contexte plomberie français
- Grow Nearby: Une entreprise de plomberie qui cherche un périmètre sectoriel plus simple autour du site, de la prise de contact, de la réservation et de la maintenance
- Thrive Internet Marketing Agency: Un acheteur qui veut comparer une offre sectorielle de site et d'hébergement, puis contractualiser séparément code, comptes, sauvegardes et sortie
Le dossier de relève relie la source, l'environnement, l'intégration et la preuve de reprise
Le premier document est une matrice de propriété. Domaine, dépôt, organisation de code, registre de paquets, CMS, hébergement, DNS, service de formulaire, routage d'appel, surveillance et sauvegarde reçoivent chacun un propriétaire institutionnel, un responsable opérationnel, un mode de récupération et une règle de transfert. Un compte personnel d'agence ne doit pas être le seul chemin d'accès.
GitHub documente des rôles d'organisation et des niveaux de responsabilité. Cette source ne certifie aucune configuration proposée par un candidat. Elle sert à demander qui possède l'organisation, qui administre le dépôt, qui peut modifier les équipes, qui approuve une fusion et comment chaque accès externe est retiré.
Le dépôt de test appartient au client fictif dès le départ. Il contient un historique, une branche protégée à décrire, un manifeste, un lockfile, des instructions de démarrage, une commande de build, des tests et un répertoire de décisions. Aucune clé n'y apparaît. Les fichiers de configuration utilisent des noms sans valeur, avec une procédure séparée pour les secrets réels.
La revue de code et l'autorisation de déployer sont deux décisions. Un développeur peut proposer une modification, un pair peut la relire et une personne responsable peut accepter une release. Le dossier enregistre la révision, les contrôles exécutés, les exceptions et l'identité du candidat à publier. Une fusion n'est pas traitée comme une preuve de fonctionnement.
Trois environnements ont des buts différents. La preview montre une révision, la recette utilise les fixtures approuvées et la préproduction reçoit l'artefact candidat. Chacun déclare données admises, accès, configuration nominale, durée de vie et nettoyage. Le pilote ne copie jamais une base de production pour rendre la démonstration plus réaliste.
La reproductibilité se vérifie hors du poste de l'agence. Un second environnement récupère la même révision, installe les dépendances déclarées et produit la même forme d'artefact. Si le build dépend d'un fichier local, d'un plugin privé ou d'une commande connue d'une seule personne, cette dépendance devient un blocage documenté.
Chaque dépendance reçoit nom, version ou plage, licence, source, fonction, responsable, mode de mise à jour, test associé et solution de retrait. Les thèmes, plugins, SDK, polices, scripts embarqués et services payants suivent la même règle. Le prix et la compatibilité juridique restent à vérifier dans la vraie proposition.
La licence d'un composant ne se résume pas au droit de l'utiliser pendant le contrat. Le client doit savoir si le code source, les fichiers modifiables, les comptes, les clés de distribution et les mises à jour restent disponibles après la sortie. Une dépendance impossible à transférer exige une alternative ou une limite explicite avant le développement.
Le CMS part d'un schéma de contenu, pas d'un écran rempli à la main. Service, zone, avis opérationnel, preuve autorisée, coordonnées et confirmation sont des types distincts. Chaque champ indique format, caractère obligatoire, source, rôle autorisé, aperçu, version, export et comportement quand la donnée manque.
WordPress documente des rôles et des capacités. FR-164 utilise cette documentation pour construire un test de permissions, sans présumer que WordPress sera retenu ni qu'une installation est sûre. L'éditeur de contenu ne doit pas modifier les extensions pour corriger une fiche. L'intégration automatique ne doit pas pouvoir publier n'importe quelle page.
Les fixtures couvrent le chemin vide et le chemin défectueux. Une zone non confirmée, une prestation absente, un numéro manquant ou un justificatif expiré doit provoquer l'état convenu avec FR-163. Le développement n'invente pas une disponibilité, une urgence ou un territoire pour éviter un bloc blanc.
Le lot visuel FR-163 est livré sous une version nommée. Il contient parcours, composants, états, libellés et règles d'affichage. Le développeur ne corrige pas une hésitation de conception dans le CSS ou le code métier. Une question repart vers le propriétaire du design et revient sous une nouvelle version approuvée.
Les données structurées sont un contrat séparé du rendu. Google Search Central publie une documentation LocalBusiness qui décrit des propriétés et des exemples de balisage. Le laboratoire utilise cette source pour vérifier que type, nom, URL et autres champs éventuels correspondent au contenu visible et approuvé. Il ne promet aucun affichage enrichi ni classement.
Le type métier précis, les zones, horaires, services et coordonnées ne sont jamais complétés par intuition. Une valeur absente reste absente ou bloque la publication selon la règle choisie. La validation vérifie syntaxe, cohérence avec la page et origine du champ, mais ne déclare pas l'entreprise éligible à une fonctionnalité de recherche.
Le formulaire possède un contrat côté navigateur et côté serveur. Champs acceptés, validation, anti-abus, état envoyé, réponse confirmée, double soumission, délai dépassé, service indisponible et réponse inattendue sont des scénarios distincts. Le message de succès ne s'affiche que lorsque la condition convenue est effectivement observée.
Le test utilise des identifiants fictifs et aucun contact. Un premier envoi réussit dans l'adaptateur local, un second devient une collision et un troisième expire. Le journal relie tentative, version du formulaire, réponse, nouvelle tentative et statut final. Une reprise automatique ne doit pas créer deux demandes à partir du même identifiant.
Le routage d'appel est également un adaptateur. Source du numéro, plage d'affichage, destination, règle horaire, état indisponible, journal minimal, consentement éventuel et chemin de secours sont documentés sans numéro réel. Si le fournisseur externe tombe, le site ne confirme pas un transfert qui n'a pas eu lieu.
Le calendrier et le CRM gardent leurs propres contrats. Entrée, sortie, version, authentification nominale, timeout, limitation, reprise, doublon, file d'erreur et désactivation sont visibles. Une modification du payload CRM doit toucher l'adaptateur et ses tests, pas forcer une réécriture du composant de présentation.
Le consentement précède les traceurs non exemptés. La CNIL rappelle sur sa page dédiée que les cookies et autres traceurs soumis au consentement ne doivent pas être déposés ou lus avant l'accord de l'utilisateur, sous réserve des cas exemptés. Le projet réel doit faire qualifier chaque usage par les responsables juridiques et données compétents.
La matrice de consentement relie finalité, traceur, déclencheur, destinataire, durée à définir, interface, version, retrait et test. Le pilote utilise seulement des états fictifs. Retirer l'accord coupe les chemins concernés et laisse les fonctions strictement nécessaires selon la décision validée, sans que l'agence interprète elle-même l'exception juridique.
La sécurité est achetée comme un ensemble d'exigences et de preuves. OWASP présente l'Application Security Verification Standard comme une base pour tester les contrôles techniques de sécurité des applications web. FR-164 transforme cette référence en questions sur authentification, autorisation, validation, configuration, journaux, dépendances et traitement des erreurs. Aucun candidat n'est déclaré conforme.
Les accès ont une durée et une raison. Développeur, mainteneur, automate de déploiement, CMS, hébergeur et outil de surveillance reçoivent le minimum défini par le propriétaire du système. Une simulation retire un collaborateur externe au milieu du pilote. Le build, le rollback et l'accès aux journaux doivent rester possibles pour l'équipe cliente.
La pipeline sépare build, tests, approbation, déploiement et vérification. Chaque étape conserve révision, artefact, environnement, résultat et acteur. Une release échoue si une configuration nominale manque ou si les contrôles requis n'ont pas été exécutés. Ce mécanisme améliore la traçabilité, sans prouver à lui seul la sécurité ou la qualité.
Deux artefacts fictifs sont déployés en recette. Le second introduit une erreur de contrat sur le formulaire. La vérification détecte l'écart entre écran de confirmation et réponse serveur, puis le runbook choisit correction ou retour à l'artefact précédent. Les migrations non réversibles sont identifiées avant l'exercice et non découvertes pendant l'incident.
Le rollback comprend code, schéma CMS, configuration nominale, intégrations et contrôles après retour. Revenir au commit précédent ne suffit pas si un contenu a été transformé ou si un service externe a changé. Le dossier précise ce qui peut être annulé automatiquement, ce qui exige une décision et ce qui nécessite une restauration séparée.
La surveillance utilise des signaux synthétiques. Route inaccessible, build échoué, certificat ou configuration à examiner, formulaire en timeout, adaptateur CRM invalide et file d'erreur bloquée deviennent des alertes de test. Signal, seuil à définir, destinataire, runbook, escalade et condition de clôture sont enregistrés sans publier de taux de disponibilité.
Un incident reçoit une chronologie factuelle. Détection, impact supposé, faits confirmés, hypothèses, action de confinement, décision, correction, contrôle et travail restant sont séparés. La rétrospective produit une modification du runbook ou du test. Elle ne fabrique ni délai de résolution ni promesse de support.
La maintenance distingue correction, mise à jour de dépendance, modification éditoriale, nouvelle intégration et changement de design. Chaque demande nomme entrée, diagnostic, décideur, branche, test, release, documentation et reste ouvert. Les horaires, niveaux de gravité et exclusions appartiennent au contrat réel, pas à ce classement.
L'export éditable est testé avant la sortie. Dépôt et historique, sources, schémas, contenus fictifs, migrations, configurations sans valeurs, dépendances, licences, tests, artefacts, décisions, journaux de test, procédures, inventaire d'accès et backlog sont livrés dans des formats convenus. Une archive d'images seule n'est pas une relève technique.
Le dernier exercice est exécuté par une équipe qui n'a pas participé au développement. Elle reconstruit l'artefact, remplace l'adaptateur d'appel, publie en recette, déclenche l'incident du formulaire et suit le rollback. Les accès de l'agence sont ensuite retirés. Si une conversation privée reste nécessaire, le dossier de sortie est incomplet.
Preuves d’adéquation sectorielle à demander
- Placez domaine, dépôt, hébergement, CMS, intégrations et surveillance sous une propriété institutionnelle récupérable.
- Liez chaque build à une révision, un manifeste, un lockfile, des commandes et des configurations sans secret.
- Documentez chaque dépendance avec version, licence, usage, responsable, mise à jour, retrait et alternative.
- Faites correspondre le schéma CMS et les données structurées aux contenus visibles, sourcés et approuvés.
- Testez formulaire, routage d'appel, calendrier et CRM avec succès, doublon, timeout, panne et désactivation.
- Séparez consentement, données strictement nécessaires, traceurs optionnels, retrait et preuve technique.
- Faites référencer par les contrôles de sécurité la révision, l'environnement, le résultat et l'exception.
- Séparez build, revue, approbation, déploiement, vérification et rollback dans la pipeline.
- Reliez chaque alerte à un runbook, une personne responsable, une escalade et une condition de clôture.
- Exigez sources, fichiers éditables, configurations, licences, procédures et backlog avant de retirer l'agence.
Comment nous avons évalué les prestataires
La sélection utilise six pages officielles de prestataires et cinq références de contrôle. Trois candidats publient une page destinée aux plombiers. Trois autres publient un périmètre d'ingénierie web plus large. Cette opposition permet de comparer connaissance sectorielle visible et profondeur technique visible sans prétendre qu'un catalogue public décrit l'équipe réellement proposée.
DynamoLogic est premier parce que sa page plomberie nomme du développement et plusieurs technologies, ce qui offre le meilleur point de départ sectoriel pour le dossier fictif. Netguru, Vention et ScienceSoft montrent davantage de couches techniques. Grow Nearby et Thrive proposent des alternatives plomberie avec des limites différentes à vérifier.
Netguru publie développement web et logiciel, API, technologies frontend et backend, CMS headless ou sur mesure, assurance qualité, ingénierie de plateforme et maintenance. Les cas, clients, prix, résultats, récompenses et formulations de supériorité n'ont pas été retenus.
Vention publie frontend, backend, services d'intégration, QA et testing, CMS, DevOps, conseil cloud et modernisation. Les modèles de collaboration visibles ne déterminent pas celui qui convient au lecteur. Direction technique, propriété et dernier artefact doivent être écrits dans la proposition.
ScienceSoft publie architecture, frontend, backend, développement d'API, tests, gestion de la qualité, maintenance, support et modernisation autour du développement web. Les garanties, chiffres d'entreprise, délais commerciaux, clients et résultats ont été exclus.
DynamoLogic publie une page Plumbing Website Development avec WordPress, PHP, Laravel, développement web, interface responsive et mobile ainsi que des fonctions liées aux demandes et à la réservation. Les chiffres, études de cas et promesses de croissance n'ont pas été utilisés.
Grow Nearby publie une page plomberie qui mentionne design et développement, intégrations de réservation et de contact, suivi analytics et performance, adaptation mobile et maintenance continue. FR-164 n'accorde aucun crédit à la partie visuelle, qui appartient à FR-163.
Thrive publie une page Plumber Web Design Company avec design et développement, WordPress, hébergement, sauvegarde, transfert de fichiers et support. Marketing, SEO, chiffres, budgets, témoignages et résultats associés ne comptent pas dans la position.
GitHub et WordPress servent à poser des questions sur rôles et permissions. OWASP fournit une base de discussion pour la vérification technique de sécurité. La CNIL fournit le repère français sur cookies et traceurs. Google Search Central fournit la référence pour les données structurées LocalBusiness. Aucune de ces sources n'évalue un prestataire.
Les critères privilégient propriété du dépôt, reproductibilité, CMS et schéma, contrats d'intégration, consentement, sécurité, release, rollback, surveillance, licences, export et reprise. Esthétique, acquisition, publicité, réseaux sociaux, référencement et performance commerciale n'ajoutent aucun point.
Le classement est un ordre de diligence éditorial fondé sur des sources T1-B de prestataires. Une page peut omettre une compétence réelle ou publier un service qui ne sera pas dans le devis. Le contrat, les personnes affectées, la démonstration isolée et les références vérifiées par l'acheteur restent nécessaires.
| Critère | Pondération | Ce qui a compté |
|---|---|---|
| Contexte plomberie et frontière du lot | 16 % | Le candidat comprend le contexte publié sans inventer service, urgence, zone, disponibilité ni décision visuelle. |
| Dépôt, architecture et build | 19 % | La source, les rôles, les décisions, les dépendances, les licences et l'artefact restent reproductibles sous contrôle client. |
| CMS, schéma et intégrations | 19 % | Contenus, permissions, données structurées, formulaires, appels, calendrier et CRM possèdent des contrats versionnés et testables. |
| Consentement, sécurité et accès | 16 % | Traceurs, finalités, erreurs, autorisations et révocation sont examinés par les responsables compétents et reliés à des preuves. |
| Release, rollback et incidents | 17 % | Build, approbation, déploiement, contrôle, surveillance, diagnostic et retour utilisent des artefacts et états distincts. |
| Maintenance, export et relève | 13 % | Sources, fichiers éditables, licences, runbooks, accès et travail ouvert peuvent passer à une autre équipe. |
Chaque prestataire devait satisfaire aux mêmes exigences minimales avant que sa position ne soit envisagée.
- Page officielle active avec réponse HTTP 200 au 31 août 2026.
- Développement web explicite ou mise en œuvre technique identifiable dans une offre plomberie.
- Au moins trois objets parmi frontend, backend, CMS, API, intégration, QA, hébergement ou maintenance.
- Périmètre traduisible en dépôt, schéma, adaptateur, test, artefact, runbook ou export.
- Aucune inclusion fondée sur un prix, une note, un client, une étude de cas, une récompense ou un résultat.
- Conception FR-163 et marketing FR-161 ou FR-162 traités comme entrées séparées, jamais comme preuve technique.
La liste de prestataires étudiée
Les classements découlent de la méthodologie publiée et de la date d’arrêt des sources ; ils ne garantissent aucun résultat. Chaque fiche indique la meilleure adéquation et la limite la plus susceptible de changer une décision d’achat.
DynamoLogic
Points forts documentés
- Page officielle dédiée aux plombiers
- WordPress, PHP et Laravel visibles
- Développement web explicite
- Demandes et réservation dans le contexte publié
Limites à confirmer
- Dépôt et pipeline non démontrés
- QA, sécurité et rollback à tester
- France et langue française non établies
- Licences, exports et relève ouverts
DynamoLogic prend la première place documentaire grâce à une page plomberie qui publie WordPress, PHP, Laravel, développement web et interface responsive. Le contexte sectoriel est visible, mais le dépôt, la pipeline, les tests, la sécurité, le rollback, les licences et la relève restent à démontrer.
La page officielle Plumbing Website Development cite des services liés à WordPress, PHP et Laravel, ainsi que du développement web et des interfaces adaptées aux usages mobiles. Elle présente aussi des fonctions de demande et de réservation dans un contexte plomberie.
FR-164 ne reprend aucun chiffre, client, cas, promesse de génération de demandes ou affirmation de performance. La source prouve un catalogue déclaré. Elle ne montre pas le code, l'architecture, l'équipe qui interviendrait en France ni le fonctionnement du support.
Le pilote demande à DynamoLogic de recevoir le lot visuel FR-163 sans le redéfinir, puis de produire dépôt, schéma CMS, formulaire local, routeur d'appel, build et artefact. PLB-ZONE reste bloqué tant que la source de zone manque.
Une panne est introduite dans l'adaptateur de formulaire. L'agence doit préserver l'état réel, diagnostiquer depuis les journaux synthétiques, revenir à la release précédente et documenter la correction. Aucun système public n'est touché.
Avant un contrat, vérifiez équipe francophone, entité contractante, sous-traitants, propriété du domaine et du code, hébergement, sécurité, consentement, licences, exports éditables et assistance de sortie. La première place ne valide aucun de ces points.
Sources sur les prestataires : DynamoLogic: Plumbing Website Development
Netguru
Points forts documentés
- Développement web et logiciel explicite
- Frontend, backend et API visibles
- CMS headless et sur mesure publiés
- QA, plateforme et maintenance dans le catalogue
Limites à confirmer
- Aucun focus plomberie dans la source
- Équipe et modèle à choisir
- Consentement et France non démontrés
- Rollback et relève à prouver
Netguru est deuxième pour la profondeur technique visible entre développement web, frontend, backend, API, CMS, QA, plateforme et maintenance. La source ne démontre aucune spécialisation plomberie. Une phase de cadrage métier et une preuve de portabilité sont donc indispensables.
La page Web Development s'inscrit dans un catalogue de développement logiciel qui publie API development, technologies frontend et backend, CMS headless et sur mesure, quality assurance, cloud and platform engineering et software maintenance.
Ces libellés permettent de préparer un lot à plusieurs adaptateurs. Ils ne prouvent ni la composition de l'équipe, ni la sécurité du code, ni la maîtrise d'un CMS donné, ni le support français. Les cas et résultats du site ont été exclus.
Netguru reçoit un formulaire, un routeur d'appel et un CMS fictifs. Le test modifie seulement le contrat CRM. Le candidat doit localiser l'adaptateur, les tests et la documentation concernés sans rouvrir les composants visuels ou le reste du site.
Le deuxième exercice reconstruit la release sur un environnement sous contrôle client. Il vérifie manifeste, lockfile, configuration nominale, artefact et procédure de rollback, sans secret ni donnée réelle.
Demandez le modèle de collaboration, la direction technique attendue côté client, les rôles, la propriété du dépôt, les licences, les sous-traitants, les procédures d'incident, le dernier artefact et le transfert complet. Le contrat doit aussi cadrer la découverte du métier plomberie.
Sources sur les prestataires : Netguru: Web Development Services
Vention
Points forts documentés
- Frontend et backend séparés
- Intégrations et CMS visibles
- QA and testing publié
- DevOps, cloud et modernisation présents
Limites à confirmer
- Pas de spécialisation plomberie démontrée
- Direction technique interne à clarifier
- Propriété et licences ouvertes
- France, données et support à confirmer
Vention est troisième parce que sa page publie frontend, backend, integration services, QA and testing et CMS, avec DevOps, cloud et modernisation dans le catalogue. Le modèle de collaboration et la propriété opérationnelle doivent être choisis par le client, et non déduits de la page.
La source officielle distingue frontend development, backend development, integration services, QA and testing et CMS. Le catalogue visible ajoute software development, DevOps, cloud consulting et legacy modernization.
Vention publie plusieurs modes de collaboration. FR-164 ne recommande aucun modèle sans contexte. Le devis doit dire qui prend les décisions d'architecture, qui relit, qui accepte, qui possède la pipeline et quel objet reste après la mission.
Le pilote isole CMS, formulaire, appel et CRM. Un timeout du routeur d'appel ne doit ni confirmer un transfert ni bloquer une modification de contenu indépendante. L'agence fournit un état de secours conforme au lot FR-163.
Une révocation intermédiaire retire un collaborateur externe. L'organisation cliente conserve le build, les journaux de test et le rollback. Le candidat montre aussi la liste des applications et automates dont l'accès devra être supprimé.
Confirmez l'entité contractante, la langue, les horaires, les sous-traitants, le traitement des données, les licences, la gestion des secrets, le support, la surveillance et l'export. Les claims commerciaux de qualité ou d'efficacité ne participent pas au rang.
Sources sur les prestataires : Vention: Web Development Services
ScienceSoft
Points forts documentés
- Architecture web visible
- Frontend, backend et API publiés
- Tests et gestion de la qualité présents
- Maintenance, support et modernisation visibles
Limites à confirmer
- Aucun focus plomberie publié
- France et langue à vérifier
- Dépôt et environnements non prouvés
- Licences, incident et sortie à tester
ScienceSoft est quatrième pour son périmètre publié autour de l'architecture, du frontend, du backend, des API, des tests, de la qualité, de la maintenance et de la modernisation. La page est techniquement large, mais ne prouve ni spécialisation plomberie ni la relève décrite.
La page Web Development décrit du web software, de l'architecture, du frontend et backend, du développement d'API, des tests, de la quality management, de la maintenance and support et de la modernization.
FR-164 exclut les garanties, chiffres d'entreprise, promesses de délai, clients et résultats. La nomenclature des services devient seulement une liste d'objets à demander dans l'offre et à éprouver dans le laboratoire.
ScienceSoft reçoit un CMS vide, une migration répétable et deux adaptateurs. Le test introduit un champ incompatible, puis vérifie erreur lisible, absence de duplication, restauration et conservation du journal.
La release suivante contient une dépendance dont la licence est marquée à vérifier. Le processus doit bloquer l'acceptation ou consigner une décision compétente. Il ne peut pas déclarer la dépendance transférable sans preuve.
Demandez équipe, juridiction, langue, modèle de support, sous-traitants, hébergement, accès, sécurité, protection des données, licences, monitoring, rollback et export. Le contexte métier plomberie doit être fourni et approuvé séparément.
Sources sur les prestataires : ScienceSoft: Web Development
Grow Nearby
Points forts documentés
- Page plomberie active
- Développement et intégrations visibles
- Réservation et contact mentionnés
- Maintenance continue publiée
Limites à confirmer
- Design hors périmètre de FR-164
- Profondeur backend non démontrée
- Sécurité et consentement à vérifier
- Dépôt, rollback et export ouverts
Grow Nearby est cinquième. Sa page plomberie publie conception et développement, intégrations de réservation et de contact, analytics, optimisation mobile et maintenance. Le design ne compte pas dans FR-164. Le dépôt, les contrats, la sécurité, le rollback et l'export demandent une preuve dédiée.
La page Plumbing Website Design and Development mentionne des intégrations de booking et contact, analytics and performance tracking, responsive design, mobile optimization et ongoing maintenance.
La conception visuelle reste chez FR-163. FR-164 retient seulement l'implémentation, les intégrations, la configuration, la maintenance et la capacité à rendre ces objets transférables. Les promesses et chiffres du fournisseur sont exclus.
Grow Nearby reçoit un formulaire local et un calendrier indisponible. L'état de secours ne crée aucun rendez-vous et conserve la tentative fictive. Le candidat doit expliquer timeout, retry, doublon, journal et reprise manuelle.
L'exercice de sortie demande code source, schéma, contenus fictifs, configuration sans secret, intégrations, fichiers éditables et procédure de maintenance. Un export de pages rendues ne suffit pas si les sources et comptes restent chez l'agence.
Vérifiez équipe française, propriété du domaine et de l'hébergement, CMS, plugins, licences, sécurité, consentement, sauvegardes, surveillance, accès et assistance après contrat. La page officielle ne certifie aucun de ces éléments.
Sources sur les prestataires : Grow Nearby: Plumbing Website Design and Development
Thrive Internet Marketing Agency
Points forts documentés
- Page officielle pour plombiers
- Développement WordPress visible
- Hébergement et sauvegarde mentionnés
- Transfert de fichiers et support publiés
Limites à confirmer
- Design et marketing doivent être exclus
- Architecture et API peu détaillées
- Sécurité, licences et données à confirmer
- Dépôt client et migration à tester
Thrive clôt la liste. La page plombier publie web design and development, responsive design, WordPress, hosting, sauvegarde, transfert de fichiers et support. Ce périmètre rend l'option testable, mais mélange des objets qui doivent rester séparés et contient moins de détail public sur l'ingénierie profonde.
La source officielle Plumber Web Design Company présente web design and development, responsive web design, WordPress website design, website hosting, contenu, backup, file transfer et support.
FR-164 n'accorde aucun point au design, au marketing, au SEO ou aux résultats commerciaux. WordPress, hébergement, sauvegarde, transfert et support deviennent des lignes de diligence technique distinctes.
Le pilote demande un dépôt sous contrôle client même si le CMS ou l'hébergement est géré. La proposition doit expliquer ce qui est versionné, ce qui se trouve dans la base, ce qui peut être exporté et ce qui dépend d'une licence ou d'un compte Thrive.
Une restauration de recette vérifie code, contenu fictif, configuration et adaptateurs. Le journal doit distinguer sauvegarde disponible, restauration exécutée et contrôle fonctionnel. Une mention commerciale de backup ne prouve pas la procédure.
Avant sélection, clarifiez français, équipe, hébergeur, WordPress, plugins, accès, mises à jour, sécurité, données, propriété des fichiers, sauvegardes, support, export et migration. Prix, statistiques, clients, leads et résultats ont été écartés.
Sources sur les prestataires : Thrive: Plumber Web Design Company
Comparez le fonctionnement sur votre propre activité
Examinez les services gérés, les contrôles de validation, les destinations de publication et les limites affichées de theStacc avant de choisir.
Quel modèle convient au niveau d'intégration du site plomberie?
Le tableau compare des périmètres officiellement publiés et les questions qu'ils ouvrent. Il ne mesure ni qualité, ni sécurité, ni performance, ni connaissance de la France.
| Prestataire | Modèle de prestation | Périmètre documenté | Idéal pour | Limite principale |
|---|---|---|---|---|
| DynamoLogic | Agence sectorielle de développement | WordPress, PHP, Laravel, web, demandes, réservation | Contexte plomberie avec exigence technique | Pipeline, sécurité et relève à prouver |
| Netguru | Équipe d'ingénierie multilayer | Frontend, backend, API, CMS, QA, plateforme, maintenance | Plusieurs systèmes et adaptateurs | Aucune spécialisation plomberie publiée |
| Vention | Projet, équipe ou renfort technique | Frontend, backend, intégration, CMS, QA, DevOps | Client avec direction technique | Modèle, propriété et sortie à cadrer |
| ScienceSoft | Développement et support multilayer | Architecture, API, tests, qualité, maintenance, modernisation | Projet technique structuré | Métier plomberie et France non prouvés |
| Grow Nearby | Site plomberie avec intégrations | Contact, réservation, analytics, mobile, maintenance | Périmètre sectoriel plus simple | Backend, sécurité et export peu détaillés |
| Thrive | WordPress géré pour plombiers | Développement, hébergement, backup, fichiers, support | Site CMS et exploitation gérée | Comptes, licences et migration à tester |
Comment mener un pilote de développement, d'incident et de relève sans données réelles
Tous les finalistes reçoivent le même lot FR-163 nommé, le même dépôt client vide, les mêmes fixtures, les mêmes adaptateurs locaux et le même incident. Aucun domaine public, numéro, contact, compte de production ou secret n'entre dans l'exercice.
La note porte sur les artefacts, les limites, les erreurs visibles et la capacité d'un autre groupe à reprendre. Une démonstration parfaite sur le chemin nominal ne compense pas un dépôt inaccessible ou une panne impossible à diagnostiquer.
1. Établissez la propriété et les rôles
Créez le dépôt dans une organisation contrôlée par le client fictif. Listez propriétaire, administrateur, développeur, relecteur, automate et voie de récupération.
Retirez un collaborateur externe en cours de pilote. Les branches, tickets, artefacts, journaux et procédures doivent rester accessibles aux rôles internes autorisés.
- Organisation
- Dépôt
- Propriétaire
- Admin
- Relecteur
- Automate
- Récupération
- Révocation
2. Reproduisez le build hors de l'agence
Consignez runtime, manifeste, lockfile, installation, build, tests, variables attendues et forme de l'artefact sans inclure de secret.
Construisez la même révision dans un second environnement. Toute dépendance locale ou manuelle devient une question bloquante avec propriétaire et correction.
- Révision
- Runtime
- Manifeste
- Lockfile
- Commande
- Configuration
- Artefact
- Écart
3. Inventoriez dépendances et licences
Enregistrez paquet, plugin, thème, SDK, police et service avec version, licence, source, fonction, mise à jour et retrait.
Marquez une licence comme non vérifiée. La release doit rester en attente ou suivre une décision qualifiée, sans supposer un droit de transfert.
- Dépendance
- Version
- Licence
- Source
- Usage
- Mise à jour
- Retrait
- Décision
4. Testez le CMS et les données structurées
Créez des contenus fictifs avec rôles, champs obligatoires, aperçu, version et export. PLB-ZONE reste bloqué faute de source métier.
Générez un balisage LocalBusiness uniquement depuis les champs approuvés. Comparez-le au contenu visible et empêchez toute valeur inventée.
- Type
- Champ
- Rôle
- Source
- Aperçu
- Export
- Balisage
- Cohérence
5. Cassez le formulaire et le routage d'appel
Simulez succès, double envoi, timeout et réponse inattendue. Le message affiché doit suivre la réponse réellement observée.
Coupez l'adaptateur d'appel. Le site propose l'état de secours approuvé et ne confirme ni connexion ni rappel.
- Formulaire
- Validation
- Doublon
- Timeout
- Appel
- Secours
- Journal
- Statut
6. Vérifiez consentement et désactivation
Associez chaque traceur fictif à sa finalité, son déclencheur, sa version, son retrait et son test. La qualification juridique reste externe.
Refusez puis retirez le consentement. Les chemins concernés restent inactifs et les fonctions jugées nécessaires sont documentées séparément.
- Finalité
- Traceur
- Déclencheur
- Version
- Refus
- Retrait
- Désactivation
- Revue
7. Reliez sécurité et accès à la release
Choisissez des contrôles techniques pertinents avec le responsable sécurité. Chaque résultat pointe vers révision, environnement, preuve et exception.
Faites expirer un accès et une configuration nominale. La pipeline doit bloquer proprement, sans révéler une valeur sensible dans le journal.
- Exigence
- Révision
- Environnement
- Preuve
- Exception
- Accès
- Expiration
- Blocage
8. Déployez puis revenez en arrière
Publiez deux artefacts en recette. Le second rompt le contrat du formulaire et déclenche le contrôle post-déploiement.
Suivez le runbook vers le premier artefact. Vérifiez code, schéma, formulaire et adaptateurs, puis consignez tout élément non réversible.
- Artefact
- Approbation
- Recette
- Contrôle
- Défaut
- Rollback
- Vérification
- Limite
9. Traitez l'incident depuis l'alerte
Déclenchez une alerte synthétique, identifiez la release et séparez faits, hypothèses, impact supposé et action de confinement.
Clôturez seulement après contrôle et attribution du travail restant. Mettez à jour test ou runbook avec la leçon observable.
- Alerte
- Release
- Faits
- Hypothèse
- Confinement
- Contrôle
- Clôture
- Suivi
10. Faites reprendre par un autre groupe
Remettez dépôt, sources, CMS, migrations, dépendances, licences, tests, artefacts, configurations sans valeurs, runbooks et backlog.
Le nouveau groupe reconstruit, change l'adaptateur d'appel, déploie et récupère l'incident. Ensuite seulement, retirez personnes, applications et automates de l'agence.
- Dépôt
- Sources
- CMS
- Licences
- Artefacts
- Runbooks
- Backlog
- Révocation
Les erreurs qui rendent un comparatif SEO inutile
- Le dépôt reste dans le compte de l'agence. Créez une propriété institutionnelle et une récupération indépendante avant le premier commit. Le transfert final est trop tardif.
- Le design change pendant l'implémentation. FR-163 fournit une version nommée. Toute question visuelle repart vers sa validation au lieu d'être tranchée en silence dans le code.
- Le message de succès précède la réponse. L'interface doit refléter le contrat serveur observé. Un timeout ne confirme ni demande, ni appel, ni rendez-vous.
- Une licence est découverte à la sortie. Inventoriez paquets, thèmes, plugins, polices et services dès le départ avec droits, comptes et alternative de retrait.
- Le balisage contient des faits absents. Les données structurées doivent venir des mêmes sources approuvées que la page visible. Le code ne complète pas une zone ou un horaire.
- Un scanner devient une certification. Reliez contrôles automatiques, examens manuels, contexte et exceptions. Un résultat isolé ne prouve ni sécurité ni conformité.
- Le rollback ne couvre que le code. Vérifiez aussi schéma, contenus, configuration et intégrations. Notez avant la release ce qui ne peut pas être annulé.
- La maintenance repose sur une conversation. Runbooks, accès, diagnostics, décisions, licences et backlog doivent être exportés pour qu'une autre équipe puisse agir.
Questions fréquentes
Demandez dépôt et historique, architecture, décisions, manifeste, lockfile, instructions de build, environnements, schéma CMS, migrations, contrats de formulaire et d'intégration, inventaire de dépendances et licences, tests, artefacts, pipeline, contrôles de sécurité, données structurées, sauvegardes, surveillance, runbooks, fichiers éditables, inventaire d'accès et backlog. Le lot visuel FR-163 reste une entrée séparée.
La page officielle associe directement plomberie, développement web, WordPress, PHP, Laravel et fonctions de demande ou réservation. Cette combinaison donne un point de départ sectoriel plus précis. Le rang ne prouve pas qualité, sécurité, conformité, maîtrise du français, présence en France, propriété du dépôt, rollback ou support. Le pilote doit encore démontrer chaque contrôle.
Une agence sectorielle peut réduire le travail de découverte sur les parcours, mais sa page publique peut montrer moins de profondeur technique. Une équipe générale peut mieux couvrir API, backend, QA et plateforme, tout en demandant un cadrage métier plus fort. Comparez le système réel, les intégrations, la capacité technique interne, les artefacts livrés et la reprise, pas seulement l'étiquette sectorielle.
L'entreprise doit conserver une propriété institutionnelle ou une garde contractuelle entièrement récupérable. Les personnes de l'agence, relecteurs et automates reçoivent des rôles limités et révocables. Documentez organisation, facturation, administrateurs, récupération, journaux, branches, applications, clés de déploiement et transfert. Testez la révocation avant la fin du contrat, sans utiliser de compte partagé.
Figez une révision et consignez runtime, manifeste, lockfile, commandes, variables attendues, tests et forme de l'artefact. Un environnement distinct, contrôlé par le client, doit produire le même type de sortie depuis les mêmes sources. N'insérez aucun secret dans la documentation. Si une étape dépend du poste ou de la mémoire d'un développeur, ouvrez un blocage.
Utilisez des fixtures et identifiants synthétiques. Testez champ invalide, double envoi, timeout, service indisponible, réponse inattendue et reprise. Comparez l'état affiché à la réponse serveur réellement reçue. Le journal doit relier tentative, version, résultat et statut final. Aucun test n'a besoin d'un nom, d'une adresse, d'un téléphone ou d'une urgence réelle.
Traitez-le comme une intégration avec source du numéro, destination, règle horaire, état indisponible, consentement éventuel, journal minimal, responsable et voie de secours. Le pilote peut utiliser un adaptateur local sans numéro. Coupez-le et vérifiez que le site n'affirme pas une connexion ou un rappel qui n'a pas été confirmé.
Tenez un registre par finalité, traceur, déclencheur, destinataire, durée à décider, version d'interface, retrait et test. La CNIL explique que les traceurs soumis au consentement ne doivent pas être déposés ou lus avant l'accord, sous réserve des exemptions applicables. Une équipe juridique et données doit qualifier chaque cas réel. L'agence ne décide pas seule de l'exemption.
Générez le balisage depuis les mêmes champs sourcés et approuvés que le contenu visible. Vérifiez type, URL, nom et propriétés réellement utilisées, puis analysez la syntaxe et les incohérences. La documentation Google LocalBusiness fournit une référence technique, pas une promesse d'affichage. N'inventez ni zone, ni horaire, ni note, ni service pour remplir le schéma.
Un rollback acceptable identifie l'artefact précédent, la compatibilité du schéma, la procédure, l'autorité, les intégrations concernées et les contrôles après retour. Il est essayé en recette avant l'incident. Revenir au code précédent peut être insuffisant si le CMS, une migration ou un service externe a changé. Les limites non réversibles doivent être connues avant la release.
Retirez personnes, équipes, applications, automates, clés de déploiement, comptes CMS, hébergement, DNS, surveillance, formulaires et intégrations selon l'inventaire approuvé. Vérifiez d'abord que le client dispose de la récupération et que le nouveau groupe peut construire, déployer, diagnostiquer et restaurer. Conservez une trace de la révocation sans exposer les secrets eux-mêmes.
Préparez la relève dès le contrat. Remettez dépôt, historique, sources, schéma CMS, migrations, contenus, dépendances, licences, fichiers éditables, configurations sans valeurs, tests, artefacts, pipeline, décisions, procédures, inventaire d'accès et backlog. Faites reconstruire et modifier une intégration par une autre équipe, puis simulez incident et rollback avant de supprimer les accès de l'ancienne agence.
Sources et politique éditoriale
Consultez les sources liées, la méthodologie et l’avis de l’éditeur de cet article. Vérifiez les tarifs, les fonctionnalités et les conditions actuels auprès de chaque prestataire ; une citation ne prouve pas à elle seule qu’un test pratique a été réalisé.
- [01]DynamoLogic: Plumbing Website Development
- [02]Netguru: Web Development Services
- [03]Vention: Web Development Services
- [04]ScienceSoft: Web Development
- [05]Grow Nearby: Plumbing Website Design and Development
- [06]Thrive: Plumber Web Design Company
- [07]GitHub Docs: rôles dans une organisation
- [08]WordPress.org: rôles et permissions
- [09]OWASP: Application Security Verification Standard
- [10]CNIL: cookies et autres traceurs, que dit la loi?
- [11]Google Search Central: données structurées LocalBusiness
Achetez une relève technique, pas seulement une mise en ligne
Commencez par la propriété du dépôt et des comptes, puis reliez chaque contenu, intégration, dépendance et release à une source, une version et un responsable. Cassez le formulaire, retirez un accès, exécutez le rollback et remettez le dossier à une autre équipe. Le site est réellement livrable lorsque cette équipe peut construire, déployer, diagnostiquer et récupérer sans dépendre de la mémoire de l'agence sortante.