Application Web Sur Mesure Ou SaaS Clé en Main

Presque aucun développement d’application web sur mesure ne commence par un cahier des charges. Il commence par un tableur que quelqu’un a créé pour suivre une seule chose, qui a gagné une deuxième colonne, puis un onglet, puis une formule qu’une seule personne comprend. Trois ans plus tard, ce fichier contient le planning, les tarifs et la moitié des fiches clients, quatre personnes le modifient en même temps, et personne ne sait dire avec certitude quelle copie fait foi.

C’est là le vrai point de décision, et ce n’est pas celui que traitent la plupart des articles sur le choix entre construire et acheter. Vous ne choisissez pas entre une page blanche et un produit. Vous choisissez entre trois sorties possibles d’un processus qui fonctionne mais reste fragile : acheter un produit, assembler quelque chose sur une plateforme no-code, ou commander un logiciel taillé sur votre façon de travailler.

Faut-il construire une application web sur mesure ou acheter du SaaS ? Achetez, sauf si au moins deux des trois conditions suivantes sont réunies : le processus est un facteur de différenciation plutôt qu’un coût de structure, aucun produit ne s’y adapte sans déformer votre façon de travailler, et le travail d’intégration constitue l’essentiel de la tâche. Si une seule est réunie, un produit accompagné de configuration revient presque toujours moins cher. Un développement sur mesure porte en outre un plancher de coût annuel d’environ 15 à 20 pour cent du prix de construction, indéfiniment.

Le tableur devenu porteur

Le schéma est assez précis pour porter un nom, et c’est en le nommant qu’une équipe se reconnaît en général.

Tout commence avec une personne et un besoin. Quelqu’un doit savoir quels chantiers sont réservés cette semaine, alors il ouvre un tableur. Une deuxième personne doit le lire, alors il passe sur un disque partagé. Puis une troisième doit le modifier, et voilà plusieurs personnes qui saisissent dans les mêmes cellules. Puis un onglet par mois. Puis une recherche dans un second fichier. Puis une macro, écrite par un prestataire parti depuis.

Les signes ne trompent pas. Le fichier porte une date et un suffixe de version dans son nom. Il existe une copie maîtresse et chacun sait qui la détient. Accueillir un nouvel arrivant consiste à lui montrer le fichier plutôt qu’à lui expliquer le processus, parce que le processus n’est écrit nulle part ailleurs.

À ce stade, le tableur n’est plus un document. C’est une application sans contrôle d’accès, sans journal d’audit, sans validation, sans politique de sauvegarde que vous oseriez défendre, et avec un seul mainteneur. Elle fonctionne, ce qui est précisément la raison pour laquelle personne ne l’a remplacée, et aussi la raison pour laquelle la remplacer coûte cher aujourd’hui.

Ce que le statu quo coûte réellement

Personne ne chiffre le tableur, il paraît donc gratuit. Il ne l’est pas, et le calcul est facile à refaire pour votre propre entreprise.

Commencez par la ressaisie. Si deux personnes passent chacune 45 minutes par jour à déplacer des données entre le tableur, le logiciel comptable et une boîte partagée, cela fait sept heures et demie par semaine, soit environ 340 heures sur une année de travail de 45 semaines. À GBP 22 de l’heure en coût complet, vous dépensez près de GBP 7 500 par an à recopier des chiffres d’un écran à l’autre, et cela n’achète rien d’autre que l’occasion de faire une faute de frappe.

Ajoutez ensuite le rapprochement, quand quelqu’un vérifie chaque mois le tableur contre la source de référence et passe une demi-journée à décider quelle version a raison. Ajoutez les erreurs détectées tard : le devis envoyé au tarif du mois précédent, le chantier réservé deux fois, le renouvellement oublié. Chacune est un petit montant et un client mécontent, et aucune n’apparaît dans une ligne budgétaire.

Ajoutez enfin le risque de dépendance à une personne. Une seule comprend les formules, et quand elle est malade, en congé ou partie, le processus se réduit à des approximations.

Des données personnelles dans un tableur restent des données réglementées

Si le fichier contient des noms, des coordonnées, des dossiers du personnel ou des informations clients, ce sont des données personnelles, et le UK GDPR s’y applique exactement comme à une base de données.

L’ICO est direct sur ce que cela exige. Son guide de la sécurité des données indique qu’un principe clé du UK GDPR est de traiter les données personnelles de manière sécurisée au moyen de mesures techniques et organisationnelles appropriées, et que ces mesures doivent garantir la confidentialité, l’intégrité et la disponibilité de vos systèmes et des données personnelles qu’ils contiennent. Un tableur sur un portable n’a ni permissions par ligne, ni règle de conservation, ni trace de qui a lu quoi, et il se recopie intégralement chaque fois que quelqu’un l’envoie par courriel.

Les conséquences ne sont pas théoriques. En octobre 2024, l’ICO a infligé une amende de GBP 750 000 au Police Service of Northern Ireland après que des données masquées dans un tableur publié en réponse à une demande d’accès à l’information ont exposé les noms, initiales, grades et fonctions de l’ensemble des 9 483 agents et employés du PSNI. L’avis d’exécution cite les articles 5(1)(f), 32(1) et 32(2). Sans l’approche de l’ICO envers le secteur public, l’amende aurait atteint GBP 5,6 millions.

Toute organisation qui fait tourner un processus sur des tableurs possède une feuille de ce genre quelque part.

Acheter le produit : quand le SaaS est manifestement le bon choix

C’est la réponse la plupart du temps, et elle mérite d’être défendue en premier plutôt qu’écartée dans un paragraphe de conclusion.

Si votre processus est courant, le produit existe, et il coûte moins cher que tout ce que vous pourriez construire. Paie, notes de frais, gestion de tickets, prise de rendez-vous, signature électronique, comptabilité, suivi des candidatures. Quelqu’un a consacré une décennie et une grande équipe d’ingénierie aux cas limites que vous n’avez pas encore rencontrés : le bogue de l’année bissextile, le changement de taux de TVA, le remboursement qui arrive après la clôture de la période.

Vous achetez aussi du travail que vous paieriez autrement. L’éditeur porte la disponibilité, les correctifs de sécurité, l’évolution des navigateurs, le travail d’accessibilité et les preuves de conformité que vos clients réclament. Rien de tout cela n’apparaît comme une fonctionnalité, et tout cela représente de l’argent réel.

Le test honnête n’est pas de savoir si le produit fait tout. Il consiste à savoir s’il fait les 80 pour cent qui comptent sans vous forcer à changer quoi que ce soit auquel vous tenez. Si le seul écart est que votre équipe parle de chantier et le logiciel de ticket, achetez le logiciel et changez le mot.

Les trois conditions qui justifient un développement d’application web sur mesure

Un développement sur mesure se justifie par la stratégie, pas par l’agacement. Trois conditions le soutiennent vraiment, et la règle utile est qu’il vous en faut au moins deux. Une condition seule se règle presque toujours moins cher avec un produit accompagné de configuration. Le même test vaut à l’échelle de l’entreprise, ce que notre guide construire ou acheter un CRM et un ERP traite à un tout autre ordre de grandeur.

Le processus est un facteur de différenciation, pas un coût de structure

Demandez ce qu’un client remarquerait si le processus devenait deux fois meilleur. Si la réponse est rien, c’est un coût de structure et vous devriez acheter, car une paie excellente ne vous gagne aucun marché. Mais un installateur spécialisé dont la logique de planification arrache un chantier de plus à la journée de chaque camionnette, ou un prêteur dont les règles d’analyse sont son produit même, fait passer son avantage concurrentiel par ce logiciel. Vous ne pouvez pas acheter un avantage que vos concurrents peuvent acheter au même prix mensuel.

Aucun produit ne convient sans déformer le processus

Chaque produit encode des hypothèses sur la façon dont le travail circule, et le signe qu’elles sont fausses pour vous, c’est que l’adopter vous obligerait à cesser quelque chose de rentable. Si votre entreprise chiffre sur une base que le produit ne sait pas exprimer, et que chiffrer ainsi est la raison pour laquelle les clients vous choisissent, le produit vous demande de devenir plus ordinaire en échange d’une redevance de licence.

La surface d’intégration est le vrai travail

Parfois, la partie intéressante n’est pas du tout dans les écrans. Elle consiste à tirer les stocks d’un système, les prix d’un deuxième, les disponibilités des techniciens d’un troisième, et à écrire le résultat dans un quatrième. Quand l’essentiel de l’effort est de l’intégration, l’interface n’est qu’une fine couche au-dessus de votre propre tuyauterie, et les écrans livrés avec un produit sont la partie dont vous avez le moins besoin. C’est la condition la plus souvent sous-estimée, et c’est là que vit le piège du milieu.

Le piège du milieu : acheter, puis construire quand même

Le résultat le plus coûteux n’est aucune des deux voies suivie proprement. C’est acheter un produit parce qu’il paraissait moins cher, puis dépenser plus à le plier à votre processus qu’un développement sur mesure n’aurait coûté, et payer la licence par-dessus.

Cela arrive progressivement et chaque étape prise isolément se défend. Le produit ne convient pas, alors vous engagez un intégrateur. Le partenaire écrit de la configuration dans la couche de script propriétaire de l’éditeur, ce qui est du code, mais n’en a pas l’air parce que cela vit à l’intérieur du produit. Puis il faut le faire dialoguer avec deux autres systèmes, alors vous achetez une plateforme d’intégration. Puis l’éditeur publie une version majeure et vos personnalisations demandent des tests de non-régression.

À ce stade, vous avez tous les coûts d’un logiciel sur mesure et aucune de ses propriétés : une base de code que vous ne pouvez pas lire, hébergée à un endroit que vous ne contrôlez pas, écrite dans un langage qui n’existe que dans un produit, maintenue par un partenaire dont le tarif journalier est désormais une ligne de votre budget. Notre guide du coût du développement logiciel sur mesure montre comment ces montants s’accumulent.

Les signes qui montrent que vous êtes dans le piège

Le piège est plus facile à repérer qu’à quitter, et les signaux sont sans ambiguïté dès qu’on les cherche.

• Les honoraires de l’intégrateur dépassent la licence de la première année.
• Quelqu’un occupe en pratique un poste à temps plein à administrer un seul produit.
• Vous avez écrit de la logique dans le langage de script propriétaire de l’éditeur, et personne hors de votre entreprise ne sait la lire.
• Chaque montée de version de l’éditeur déclenche des tests de non-régression sur vos personnalisations, alors vous repoussez les montées de version.
• Vous payez une plateforme d’intégration qui n’existe que pour alimenter ce produit en données.
• Vous entretenez un tableur parallèle à côté du produit, parce que le produit ne sait pas exprimer une chose dont vous avez besoin.

Ce dernier point est le plus clair. Si le tableur a survécu à l’achat du logiciel, le logiciel n’a pas résolu le problème.

Le no-code et le low-code comme troisième voie sérieuse

La question du no-code face au sur mesure mérite mieux qu’une note de bas de page, car pour le développement d’outils internes les plateformes low-code sont souvent la bonne réponse et ne sont pas des jouets.

Des plateformes comme Airtable, Retool et Microsoft Power Apps vous laissent construire une vraie application multi-utilisateur avec base de données, formulaires, permissions et automatisations, en jours plutôt qu’en mois, sans recruter personne. Elles prennent en charge l’hébergement, les sauvegardes, l’authentification et la mise en page mobile. Pour la tâche précise consistant à faire passer un tableur porteur vers quelque chose doté d’un vrai contrôle d’accès et d’un journal d’audit, elles sont souvent la voie la plus rapide vers une forte réduction du risque.

Elles sont aussi facturées par siège, et c’est ce fait qui détermine si elles restent la bonne réponse à mesure que vous grandissez.

Là où le no-code gagne vraiment

Il gagne quand la forme du problème tient en enregistrements, formulaires, vues et règles simples : un registre d’actifs, une file de validations, une liste de contrôle d’accueil client, une réservation de salles. Il gagne surtout quand la personne qui comprend le processus peut le construire elle-même, car les exigences n’ont alors jamais à survivre à une traduction en spécification puis retour.

Il gagne aussi sur le délai d’obtention de valeur. Un outil qui fonctionne en deux semaines et sert tous les jours vaut mieux qu’un outil parfait en six mois encore en conception, et la version construite vous apprend quelles étaient vraiment les exigences.

Là où le no-code se heurte à un mur

Le mur est en général l’une de cinq choses. La performance sur des volumes de lignes réels, dès qu’une vue doit filtrer des centaines de milliers d’enregistrements. Les permissions un peu complexes, par exemple des règles par ligne dépendant de l’état de l’enregistrement et de l’équipe de celui qui regarde. L’intégrité transactionnelle, où deux choses doivent se produire ensemble ou pas du tout. Les tests et la gestion de versions, car il n’existe souvent aucun moyen de relire un changement avant sa mise en ligne. Et tout ce qui comporte une véritable machine à états, où des règles gouvernent les transitions autorisées.

Vous n’atteignez pas le mur progressivement. Vous l’atteignez quand un changement qui devrait prendre une heure se révèle impossible.

Ce que la facturation par siège produit à grande échelle

La facturation par siège est bon marché à dix utilisateurs et peut devenir indéfendable à quatre cents, et les tarifs publiés le démontrent facilement.

La page de tarifs de Retool affiche son offre Business pour le cloud britannique à GBP 40 par mois et par concepteur et GBP 12 par utilisateur interne, l’offre Team étant à GBP 8 et GBP 4. Microsoft affiche Power Apps Premium à GBP 16,90 par utilisateur et par mois en paiement annuel, hors TVA, tombant à GBP 10,80 avec un minimum de 2 000 sièges. Airtable publie Team à USD 20 et Business à USD 45 par utilisateur et par mois, tous deux facturés annuellement en dollars américains.

Projetez cela. Quarante utilisateurs sur Retool Business, dont trois concepteurs, reviennent à environ GBP 6 800 par an. La même configuration à quatre cents utilisateurs revient à près de GBP 59 600 par an, et elle remonte dès que vous ajoutez des personnes. Sur Power Apps Premium, quatre cents sièges coûtent environ GBP 81 000 par an avant TVA.

Aucun de ces tarifs n’est déraisonnable. Ce qui compte, c’est que la facture suit l’effectif plutôt que la valeur livrée, et que l’effectif grandit.

Le problème de sortie quand la logique vit dans un outil propriétaire

Toute plateforme exportera vos données. Aucune n’exportera votre application.

Les lignes sortent en CSV ou par une interface de programmation, et c’est la partie que tout le monde vérifie avant de signer. Ce qui ne sort pas, c’est ce que vous avez construit : les automatisations, les colonnes de formules, les règles de permission, les formulaires conditionnels, le flux qui transforme une demande en trois notifications et un changement de statut. Cette logique est l’actif, elle a demandé des mois de décisions, et seul le moteur d’un éditeur sait l’exécuter.

La conséquence pratique est que quitter une plateforme low-code n’est pas une migration, c’est une reconstruction. Vous récupérez vos données et vous réécrivez l’application ailleurs, à partir d’une spécification qui n’a jamais été écrite parce que la plateforme était la spécification.

Ce n’est pas un argument contre l’usage de ces plateformes, seulement en faveur d’une description écrite des règles conservée hors de l’outil.

Coût total de possession sur cinq ans pour les trois voies

La comparaison que l’on fait d’habitude est malhonnête d’une manière précise : elle oppose la version pleinement chiffrée d’une voie au prix affiché de l’autre. Prenez quarante utilisateurs et une application opérationnelle qui remplace un tableur et deux petits abonnements. Les chiffres sont des valeurs de planification illustratives, pas des devis, et votre prix de construction est la variable qui bouge le plus.

En prose : à quarante utilisateurs, la plateforme no-code gagne, à environ GBP 75 800 sur cinq ans. Le sur mesure arrive deuxième à près de GBP 94 500, car une construction à GBP 45 000 plus GBP 1 800 d’hébergement et GBP 8 100 de maintenance annuelle bat encore la licence, le middleware et l’administration empilés de la voie SaaS. Acheter le produit finit dernier à près de GBP 135 000, et c’est le piège du milieu qui l’explique, pas la licence seule.

Pourquoi le même tableau s’inverse à quatre cents utilisateurs

Changez une seule donnée, l’effectif, et l’ordre change du tout au tout. C’est la raison la plus courante pour laquelle une construction devient rationnelle.

À quatre cents utilisateurs, la licence SaaS à GBP 30 par siège et par mois représente GBP 144 000 par an à elle seule, et avec le même middleware et une charge d’administration plus lourde, le total sur cinq ans dépasse GBP 800 000. La voie no-code atterrit près de GBP 375 000. Le sur mesure bouge à peine : plus d’utilisateurs signifie une facture d’hébergement et un budget de maintenance un peu plus élevés, si bien que même en doublant le prix de construction à GBP 70 000, le total sur cinq ans reste près de GBP 153 000.

La raison est structurelle. La facturation par siège est un coût variable qui croît avec votre organisation, tandis qu’un système sur mesure est un coût fixe assorti d’une petite part variable, et cette part est de l’infrastructure, qui coûte peu. Savoir si cette inversion vous concerne relève de la prévision d’entreprise et non du jugement technique.

Le plancher de coût permanent d’un développement sur mesure

La ligne que l’on omet dans une estimation sur mesure est celle qui ne s’arrête jamais. Une application sur mesure a un plancher de coût, et il ne tombe pas à zéro dans une année calme où personne ne demande de fonctionnalité.

Ce plancher est fait d’hébergement, de supervision, de sauvegardes dont vous avez testé la restauration, de certificats TLS, de correctifs de sécurité, de mises à jour de dépendances, et de quelqu’un qui répond au téléphone quand cela casse un lundi à neuf heures. Prévoyez environ 15 à 20 pour cent du coût de construction initial par an. C’est une hypothèse de planification tirée du comportement de ces projets et non une statistique publiée, mais c’est le chiffre sur lequel nous budgétons, et un devis établi sans cette ligne n’est pas un devis complet. Notre article sur le coût de maintenance logicielle le détaille davantage.

Chaque total sur cinq ans du sur mesure ci-dessus suppose que cette ligne est financée. Les projets qui la sautent n’économisent pas cet argent, ils le reportent et le paient plus tard sous forme de réécriture, ce qui est exactement ce que décrit la dette technique.

Un logiciel qui n’est pas maintenu se dégrade

Une application qui tourne sans être touchée depuis deux ans n’est pas stable. Elle n’est pas corrigée, et la différence compte.

Rien n’a changé dans votre code, mais tout a changé autour. Les environnements d’exécution atteignent leur fin de vie selon un calendrier publié : Node.js prend actuellement en charge la version 26 comme Current, avec les versions 24 et 22 comme lignes LTS actives, ce qui signifie que tout ce qui repose sur la version 20 ou antérieure n’est plus suivi et ne reçoit plus de correctifs de sécurité. Les dépendances accumulent des vulnérabilités publiées. Les navigateurs changent leur traitement des cookies et du stockage. Les prestataires de paiement retirent des versions d’interface et vous fixent une date limite.

Rien de tout cela n’est de votre faute et tout cela est votre problème, car dans un système sur mesure aucun éditeur ne l’absorbe à votre place. C’est l’avantage réel et structurel de l’achat : l’équipe d’ingénierie de quelqu’un d’autre passe chaque semaine à empêcher le plancher de pourrir, et la redevance de licence est le prix de ce travail. Votre propre budget de maintenance achète exactement le même travail, et vous le payez soit délibérément, soit dans l’urgence.

Trouver votre propre point de bascule par siège

Vous pouvez calculer le point de bascule en une dizaine de minutes, et il convainc une direction financière mieux que n’importe quel argument sur la propriété.

Prenez le coût mensuel de la voie produit, tout compris : licence, middleware, et la fraction de salaire consacrée à son administration. Retranchez le coût mensuel de fonctionnement d’un système sur mesure, soit l’hébergement plus un douzième du budget annuel de maintenance. Divisez le prix de construction par ce qui reste. Le résultat est le nombre de mois avant que la construction ne se soit remboursée.

Le calcul à quarante utilisateurs : la voie SaaS tourne à environ GBP 2 150 par mois et le système sur mesure à environ GBP 825, l’économie mensuelle est donc de près de GBP 1 325. Une construction à GBP 45 000 s’y divise environ 34 fois, le retour tombe donc vers deux ans et dix mois. À quatre cents utilisateurs, le retour passe sous un an.

Deux réserves. Le prix de construction est ici le chiffre le moins certain, calculez-le donc avec votre devis puis de nouveau avec 50 pour cent de plus. Et un retour de plus de trois ans environ constitue un dossier faible, car votre processus ne survivra peut-être pas inchangé aussi longtemps.

Les données et l’enfermement coupent des deux côtés

L’enfermement propriétaire est l’argument classique en faveur de la construction, et il est réel. Il ne dit pourtant que la moitié de l’histoire, car un système sur mesure que personne n’a documenté enferme lui aussi.

Du côté du produit, vérifiez avant de signer ce qui sort vraiment. Les enregistrements s’exportent en général proprement. Les pièces jointes, les journaux d’audit historiques, les fils de commentaires, les structures de permissions et les relations entre enregistrements, souvent pas. La mesure pratique n’est pas de savoir s’il existe un bouton d’export, mais si vous pourriez monter un remplaçant fonctionnel à partir du seul export.

Du côté du sur mesure, le risque égal et opposé est un système construit par un seul prestataire sans README, sans tests, sans manuel d’exploitation, avec des identifiants dans un fichier de configuration sur un portable et un dépôt dans le compte personnel de quelqu’un. C’est pire que l’enfermement SaaS, car l’éditeur, lui, est au moins encore en activité.

Les remèdes sont contractuels et peu coûteux à exiger dès le départ. Détenez le dépôt vous-même, exigez la documentation et un manuel d’exploitation comme livrables nommés, et exigez qu’un deuxième ingénieur puisse déployer à partir de cette seule documentation. Testez cette promesse avant le paiement final. Notre guide complet de l’acheteur traite les clauses contractuelles plus en détail.

Sécurité et conformité selon chaque modèle

Le partage des responsabilités change selon la voie, mais une chose ne bouge pas du tout, et se tromper là-dessus est fréquent.

Sous le UK GDPR, vous êtes le responsable du traitement. L’ICO définit le responsable du traitement comme l’organisme qui, seul ou conjointement avec d’autres, détermine les finalités et les moyens du traitement de données personnelles, et le sous-traitant comme celui qui traite des données personnelles pour le compte du responsable. Votre éditeur SaaS est presque toujours le sous-traitant. Il vous revient de démontrer la conformité, et l’ICO dit explicitement qu’un responsable répond de ses sous-traitants et doit détenir un contrat contraignant comportant les dispositions exigées par l’article 28(3).

Ce que l’éditeur porte vraiment, c’est la couche d’infrastructure : sécurité physique, correctifs de plateforme, contrôles réseau et souvent des certifications. Le modèle de responsabilité partagée du NCSC est clair : même avec du SaaS, trois choses vous restent, évaluer que le service répond à vos besoins de sécurité, le configurer de manière sûre, et décider quelles données vous y placez.

Dans un développement sur mesure, vous héritez en plus de toute la couche technique : correctifs, contrôle d’accès, chiffrement, journalisation, sauvegarde et restauration. Notre article sur la conformité technique au RGPD montre à quoi cela ressemble dans le code. La position juridique ne change pas d’une voie à l’autre.

L’accessibilité s’applique aussi aux outils internes

Les outils internes sont couramment construits comme si personne parmi leurs utilisateurs ne pouvait être en situation de handicap, ce qui est faux et, pour certaines organisations, illégal.

En vertu de l’article 20 de l’Equality Act 2010, un employeur a l’obligation de prendre des mesures d’aménagement raisonnables, y compris les mesures qu’il est raisonnable de prendre pour éviter un désavantage substantiel causé par une disposition, un critère ou une pratique, et de fournir des aides auxiliaires. Un système de planning qui ne s’utilise pas au clavier place un employé handicapé dans un désavantage substantiel, et il n’existe aucune exemption pour un logiciel que vos clients ne voient jamais.

Pour les organismes du secteur public, la position est explicite. Le guide de GOV.UK sur les exigences d’accessibilité indique que les sites intranet et extranet sont couverts par la réglementation sur l’accessibilité, qu’ils doivent respecter les WCAG 2.2 AA, et que les anciens sites internes publiés avant le 23 septembre 2019 doivent être rendus accessibles lorsqu’ils sont mis à jour.

Les critères que les outils internes échouent le plus souvent sont les plus banals : 2.1.1 Clavier et 3.3.2 Étiquettes ou instructions au niveau A, 1.4.3 Contraste (minimum) au niveau AA, et parmi les ajouts des WCAG 2.2 les critères 2.4.11 Focus non masqué (minimum) et 2.5.8 Taille de la cible (minimum), tous deux au niveau AA.

En no-code, l’accessibilité est un plafond que vous ne contrôlez pas

C’est le point d’accessibilité qui modifie une décision entre construire et acheter au lieu de simplement lui ajouter du travail.

Sur une plateforme no-code, vous n’écrivez pas le balisage. La plateforme le produit, si bien que l’accessibilité de votre application est plafonnée par celle de la bibliothèque de composants de la plateforme. Si son sélecteur de date ne s’utilise pas au clavier, ou si sa fenêtre modale piège mal le focus, vous ne pouvez pas le corriger. Vous pouvez ouvrir un ticket de support et attendre.

Cela convient tant que le plafond est assez haut, et plusieurs plateformes prennent le sujet au sérieux. Cela ne convient pas quand vous avez une obligation précise, un employé précis ou un devoir de service public, car le remède se situe hors de votre contrôle et hors de votre calendrier.

Dans un développement sur mesure, le travail d’accessibilité vous revient, ce qui coûte plus cher au départ et supprime la dépendance. Demandez à tout éditeur pressenti une déclaration de conformité en matière d’accessibilité avant de concevoir un processus autour de ses composants, et traitez son absence comme une réponse.

Réduire le risque d’un développement sur mesure par une première tranche fine

Les projets sur mesure échouent rarement pour des raisons techniques. Ils échouent parce qu’on engage tout le budget sur une spécification écrite avant que quiconque ait utilisé quoi que ce soit.

L’alternative est une tranche fine : un flux de travail, de bout en bout, en production, utilisé par une personne réelle faisant un travail réel, en six à huit semaines. Ni maquette ni démonstration, mais le chemin le plus étroit à travers le système qui produit un résultat véritable, avec de vraies données, une vraie authentification et un vrai déploiement. Si le processus est le devis, la tranche crée un devis, le chiffre et l’envoie.

Cette tranche fait quatre choses qu’une spécification ne peut pas faire. Elle prouve les intégrations, là où vivent les surprises. Elle mesure la vitesse réelle de livraison de l’équipe au lieu de l’estimer. Elle met un logiciel qui fonctionne devant la personne dont c’est le processus, ce qui change les exigences à coup sûr. Et elle vous donne une sortie : vous avez dépensé un montant défini et vous possédez quelque chose qui marche.

Placez ensuite un point de décision à cet endroit, par écrit, avant de libérer la dépense plus lourde. Notre guide pour construire une application web traite la forme technique d’une première tranche, et notre page de services de développement logiciel explique comment nous en cadrons une.

Un cadre de décision que vous pouvez dérouler en un après-midi

Rien de tout cela n’exige une mission de conseil. Il faut quelques heures et de l’honnêteté sur les chiffres.

D’abord, écrivez le processus tel qu’il se déroule vraiment, par étapes, exceptions traitées à la main comprises. Cela seul met souvent fin au débat, car il en ressort qu’il y a trois processus et non un seul.

Ensuite, comptez les sièges d’aujourd’hui et projetez-les sur trois ans. Troisièmement, présélectionnez exactement trois produits et notez-les face à votre processus écrit plutôt que face à leurs listes de fonctionnalités, en marquant chaque endroit où l’adoption changerait votre façon de travailler et si ce changement vous coûte quelque chose.

Quatrièmement, chiffrez explicitement le piège du milieu : honoraires d’intégration, middleware, et la fraction de salaire qui l’administrera. Cinquièmement, appliquez le test des deux conditions sur trois. Sixièmement, calculez le point de bascule en mois pour les deux effectifs. Septièmement, si la réponse est le sur mesure, commandez une tranche fine plutôt qu’un système.

Qui devrait fermer cet onglet et aller acheter quelque chose

Certains lecteurs devraient s’arrêter ici, et le dire franchement est plus utile qu’une conclusion équilibrée.

Si votre processus est courant et que des milliers d’entreprises le mènent à peu près de la même façon, achetez le produit. Si vous avez moins d’une vingtaine d’utilisateurs et aucune prévision qui change cela, achetez le produit ou construisez-le sur une plateforme no-code, car l’arithmétique par siège ne tournera pas en votre faveur dans un horizon planifiable. Si personne ne prendra la responsabilité du logiciel après sa livraison, achetez le produit, car un système sur mesure sans propriétaire devient vite un passif.

Si vous ne savez pas décrire votre processus par écrit, ne commandez encore rien. Écrivez-le d’abord. Beaucoup de projets ratés ont été commandés sur une description que trois personnes dans la même pièce comprenaient différemment, et aucune quantité d’ingénierie ne répare cela.

Si une seule des trois conditions est réunie, achetez le produit et réexaminez dans un an. Les conditions changent, en général parce que l’effectif a grandi. Et si ce dont vous avez besoin est en réalité un site public plutôt qu’un outil interne, c’est un autre projet, couvert par notre travail de développement de sites web.

Prendre un deuxième avis avant de vous engager

L’erreur coûteuse, dans un sens comme dans l’autre, se commet avant qu’aucune ligne de code n’existe, si bien que la chose la moins chère à acheter maintenant est une évaluation honnête.

Mecanik construit des applications web opérationnelles pour des entreprises britanniques, et une grande part de ce travail consiste à dire aux gens qu’ils n’en ont pas besoin. Apportez le tableur, le nombre de sièges et les trois produits présélectionnés, et notre équipe de développement logiciel sur mesure chiffrera soit une première tranche fine, soit vous dira quel produit acheter à la place. Si l’application s’adresse aux clients plutôt qu’aux équipes internes, commencez par le développement de sites web et lisez la comparaison développement web sur mesure face aux plateformes SaaS, qui traite ce versant de la question.

Questions fréquentes

Combien coûte une application web sur mesure au Royaume-Uni ? Une application interne ciblée qui remplace un tableur et un ou deux abonnements coûte en général de GBP 25 000 à GBP 60 000 à construire, dont une première tranche fine représente de GBP 8 000 à GBP 15 000. Prévoyez chaque année 15 à 20 pour cent de plus du prix de construction pour l’hébergement, les correctifs et les mises à jour de dépendances, car ce plancher de coût n’atteint jamais zéro.

Le no-code est-il une vraie alternative au développement d’application web sur mesure ? Oui. Pour des enregistrements, des formulaires, des vues et des règles simples, c’est souvent la bonne réponse et c’est bien plus rapide. Il se heurte à un mur sur les gros volumes de lignes, les permissions complexes, l’intégrité transactionnelle, la gestion de versions et les vraies machines à états. Il est aussi facturé par siège : Retool affiche son offre Business à GBP 40 par concepteur et GBP 12 par utilisateur interne et par mois, ce qui est bon marché à dix sièges et considérable à quatre cents.

À partir de combien d’utilisateurs construire devient-il moins cher qu’acheter ? Divisez le prix de construction par l’économie mensuelle, soit le coût produit tout compris moins l’hébergement plus un douzième du budget annuel de maintenance. À quarante utilisateurs, une construction à GBP 45 000 face à un coût produit mensuel de GBP 2 150 se rembourse en environ 34 mois. À quatre cents utilisateurs, elle se rembourse en moins d’un an, car les frais par siège suivent l’effectif alors que le coût de fonctionnement d’un système sur mesure bouge à peine.

Qui est responsable de la protection des données si nous achetons du SaaS plutôt que de construire ? Vous. L’ICO définit le responsable du traitement comme l’organisme qui détermine les finalités et les moyens du traitement, et votre éditeur SaaS est presque toujours le sous-traitant agissant sur vos instructions. Il vous revient de démontrer la conformité, de répondre de celle de vos sous-traitants et de détenir un contrat au titre de l’article 28(3). Acheter un logiciel déplace le travail d’infrastructure, pas la responsabilité juridique.

Les règles d’accessibilité s’appliquent-elles aux outils internes que personne ne voit de l’extérieur ? Oui. L’article 20 de l’Equality Act 2010 impose aux employeurs des aménagements raisonnables, et un outil qui ne s’utilise pas au clavier place un employé handicapé dans un désavantage substantiel. Les intranets et extranets du secteur public relèvent en plus de la réglementation sur l’accessibilité et doivent respecter les WCAG 2.2 AA. Sur une plateforme no-code, le plafond d’accessibilité est fixé par les composants de l’éditeur.