Produit du marché ou logiciel sur mesure : lequel choisir, et quand

Vous achetez un CRM, parce que le responsable des ventes n’arrive plus à suivre avec ses notes, et trois mois plus tard, à côté du système, il y a un Excel avec trois listes de prix et un dossier de factures que quelqu’un recopie dans la comptabilité. Le produit n’est pas moins bon que ce pour quoi on l’a vendu, parce qu’il connaît le client, l’affaire et le prochain appel, mais il ne connaît pas votre processus, parce que ce processus n’était pas celui que l’éditeur construisait pour des centaines d’entreprises, et cet écart est tout le sujet de cet article : achetez-vous un outil pour votre processus, ou un processus pour votre outil, et non le trou d’une liste de fonctions qu’un seul ajustement viendrait combler. Si le trou est un raccord entre des systèmes qui font déjà leur travail, ce n’est pas un argument pour construire : d’abord, nous branchons ce qui est déjà là.

Produit du marché ou logiciel sur mesure : lequel choisir, et quand, n’est pas une question de bouton plus moderne, ni une question de savoir si vous « êtes assez grands pour construire vous-mêmes ». Notre réponse est celle que nous avons écrite sur la page de service : si votre processus tient dans un outil du marché, prenez l’outil du marché, ce sera moins cher, et un système sur mesure se justifie quand le processus fait partie de votre compétitivité ou que les solutions toutes faites exigent trop de compromis, et cette phrase n’est pas un tour de vente pour vous vendre ensuite une construction, mais le test avec lequel nous perdons les lignes où il faudrait écrire encore un CRM, et nous gardons celles où le processus est une part de la compétitivité ou où les outils du marché exigent trop de compromis.

Cet article n’est pas une comparaison de plateformes de site e-commerce, parce que nous l’avons déjà écrite ailleurs, et ce n’est pas non plus une grille du logiciel sur mesure, parce qu’un tel article, nous ne l’avons pas et nous n’en aurons pas, parce que nous n’inventons pas les prix, et ce n’est pas non plus la promesse que votre propre système l’emporte toujours. Nous vendons à la fois la mise en place d’un produit du marché et la construction à partir de zéro, et un texte honnête commence par ceci : parfois le service le plus cher que nous puissions vous vendre est celui dont vous n’avez pas besoin, c’est pourquoi, plus bas, se trouve la frontière à partir de laquelle on peut faire ce choix, avant que quelqu’un vous vende un sprint.

Produit du marché ou logiciel sur mesure : lequel choisir, et quand

Prenez le produit du marché si le processus y tient, et commandez un logiciel si le processus est votre compétitivité ou que les outils du marché exigent trop de compromis : c’est toute la réponse, et le reste de cet article est la façon de vérifier cette phrase contre un travail concret, non contre une présentation. Une comparaison qui commence par un tableau de fonctions s’achève avant d’avoir commencé, parce que le tableau montre ce que l’éditeur a nommé, non qui, dans un an, décidera de votre prochain changement.

Les conséquences du mauvais côté ne sont pas symétriques, parce que l’outil du marché dans lequel vous avez forcé votre processus devient un abonnement plus un Excel plus une personne qui tient les deux ensemble, et cette personne, au bout d’un an, coûte plus cher que n’importe quelle licence, mais un système sur mesure pour un processus qui vit déjà dans la comptabilité, le logiciel de messagerie et un CRM standard est une construction que vous maintiendrez vous-mêmes, alors que le marché la maintient déjà. Dans le premier cas, vous avez acheté un produit puis écrit un second système à côté ; dans le second, vous avez écrit un système là où une licence suffisait, et les deux erreurs se paient plus longtemps qu’il n’y paraît dans l’offre.

Nous nommons cette frontière parce que nous en avons vu les deux bouts dans la même semaine : une entreprise qui voulait « son propre HubSpot », alors qu’il lui fallait HubSpot, et une entreprise qui, trois ans durant, a plié un ERP du marché autour de sa table de prix et est finalement venue avec cette même table comme un projet neuf, non parce que « l’ERP ne sait pas », mais parce que les compromis dépassaient déjà la configuration. Aucun de ces états n’est le fruit d’une mauvaise volonté, parce que les deux commencent par la phrase « il nous faut un système », qui n’est pas encore un test, et le test ne commence que lorsque vous écrivez le processus sur une page, sans nom d’outil, puis cherchez quel outil fait déjà cette page.

Avant l’achat, écrivez ce que le système doit faire le premier jour, ce qu’il n’a pas le droit d’oublier la deuxième année, et qui a le droit de changer cette deuxième année sans attendre la version d’un autre, parce que, si les réponses tiennent dans un produit que l’on peut configurer, prenez le produit. Si la question est un catalogue, des prix, une commande et une livraison dans un site e-commerce, c’est le test de la boutique, et nous ne le réécrivons pas ; si les réponses sont un processus qu’un concurrent n’a pas le droit d’acheter comme un outil du marché, alors seulement il vaut la peine de parler d’un sprint. Cet article, plus loin, vend cet ordre, non un outil.

Ce qu’est un produit du marché, et ce qu’est un logiciel sur mesure

Le produit du marché est un logiciel qu’un autre a déjà écrit pour beaucoup, et que vous achetez ou auquel vous vous abonnez pour l’utiliser sans reconstruction substantielle. La doctrine de l’État sur les achats publics numériques, précisée le 6 février 2026 pour les administrations, dit d’abord de s’appuyer sur les solutions déjà disponibles — mutualisées en interne ou proposées par le marché — et de n’engager un développement spécifique qu’en dernier ressort, lorsqu’aucune solution existante ne répond au besoin ou que la résilience exige une maîtrise interne. COTS désigne un logiciel commercial prêt à l’emploi, que l’on peut acquérir et utiliser sans adaptation substantielle, et le SaaS (logiciel en tant que service) est une application disponible sur Internet sous forme d’abonnement. Ce sont des définitions pour planifier, non un devoir imposé à une entreprise privée, et nous les prenons ici comme des mots déjà nommés, non comme une loi qui vous soumettrait à cette doctrine.

Le logiciel sur mesure est un système écrit pour votre processus, et un logiciel spécialisé, dans notre usage, désigne un logiciel développé individuellement pour les besoins d’une institution ou d’un secteur. Nous l’appelons aussi système sur mesure, sur la page de service, système hors normes, et dans le titre, logiciel sur mesure, et ce ne sont pas trois produits, mais un seul travail : un code qui part de votre processus, non de l’hypothèse de l’éditeur sur ce qu’est un client, une commande ou une facture, si bien que la différence n’est pas « meilleur » contre « moins bon », mais qui, ensuite, a le droit de changer cette hypothèse.

Le produit du marché n’est pas une construction sur mesure ratée, et une construction sur mesure n’est pas un meilleur CRM, parce que WooCommerce est un produit e-commerce du marché, Moodle est une plateforme de formation du marché, WordPress est une plateforme de contenu du marché, et nous vendons les trois comme une mise en place, non comme une construction cachée sous un autre nom. Laravel n’est pas un produit en ce sens : c’est un framework sur lequel nous écrivons des systèmes sur mesure depuis la version 4.0, en 2013, et il ne donne ni catalogue, ni panier, ni CRM tant que personne ne les a écrits, si bien que confondre un framework avec un produit, c’est s’imaginer que « sur Laravel » est déjà une réponse, alors que ce n’est qu’une façon d’écrire la réponse.

La troisième chose que l’on mélange d’ordinaire ici, c’est l’abonnement contre la propriété, parce que le SaaS signifie que vous payez l’usage et que les données sont chez le fournisseur, qu’une licence perpétuelle signifie que vous avez payé le droit d’utiliser une version et que les mises à jour sont souvent une ligne à part, mais que le code sur mesure que nous remettons signifie que le code source, la documentation et la configuration de l’infrastructure sont à vous. Dans aucune de ces lignes il n’y a de victoire automatique, il y a seulement la clarté de ce que vous achetez, faute de quoi, un an plus tard, vous discutez pour savoir si « le système est le nôtre » alors qu’il s’agit d’un abonnement que l’on peut résilier.

Le test avec lequel nous faisons ce choix

Le test n’est pas « est-ce que cet écran nous plaît », mais si le processus que vous n’avez pas le droit de céder à un concurrent tient dans un outil que le concurrent peut acheter dans le même magasin : s’il y tient, l’outil est la bonne réponse, parce que ce sera moins cher et que quelqu’un dont c’est le seul métier le maintiendra, mais, s’il n’y tient pas, parce que la table de prix, la validation de commande ou les règles de livraison sont ce qui vous distingue, alors le produit du marché devient un compromis, et le compromis, ici, signifie que le processus commence à vivre dans un Excel à côté du système.

L’autre face du même test s’oublie trop souvent, parce que les besoins sont plus souvent communs qu’uniques, et l’on ne construit pas un logiciel de messagerie, l’on ne construit pas une comptabilité qui fait déjà ce que la loi exige, et l’on ne construit pas non plus un entonnoir de vente standard où une affaire est une affaire. Les administrations qui dépensent leur argent selon des critères écrits ont nommé la même forme autrement : d’abord demander si la chose existe déjà sur le marché, et ne construire que lorsque les produits disponibles ne couvrent pas le cœur ou lorsqu’il faut maîtriser la chose soi-même, et ce n’est pas le devoir d’une entreprise privée, et nous n’en faisons pas un, mais c’est la même forme avec laquelle nous disons non à une construction que l’on peut acheter.

La troisième erreur est de reconstruire un produit jusqu’à ce qu’il ne soit plus un produit, parce que la configuration reste dans les limites prises en charge (les champs, les rôles, les flux que l’éditeur a prévus), mais l’adaptation qui réécrit le cœur pour que le processus « tienne enfin » dépense précisément l’avantage pour lequel on avait acheté le produit : les mises à jour, la documentation, le fait qu’un autre trouve le bogue. Nous l’avons vu dans des mises en place Moodle, où nous vérifions d’abord si une extension existe déjà, et seulement ensuite nous écrivons la nôtre, et sur des sites WordPress, où nous ne posons pas de thème tout fait, parce qu’il apporte des dizaines de fonctions dont vous n’avez pas besoin et qui deviennent un risque de sécurité, si bien qu’un produit au cœur étranger n’est pas un système sur mesure, mais un produit auquel vous avez retiré le cœur de l’éditeur.

Nous faisons ce test dans l’atelier de cadrage, non sur une diapositive d’offre, parce que, sur la diapositive, gagne toujours la construction qui a l’air de se soucier de vous, mais, dans l’atelier, gagne le processus que l’on peut nommer. Si, au bout de deux jours, il apparaît que le processus tient dans un outil du marché, nous le disons, y compris lorsque cela signifie que l’affaire de la semaine n’est pas notre système hors normes, parce qu’un article qui s’achève toujours par « nous vous construirons le vôtre » n’est pas un test, mais une offre qui se cache derrière une question.

Quand le produit du marché est la bonne réponse

Le produit du marché est la bonne réponse là où le processus est déjà nommé dans le secteur et où vous n’êtes pas ceux qui ont inventé ce nom, parce que le courrier électronique, la comptabilité qui émet une facture comme la loi l’exige, un CRM de vente standard, une plateforme de formation qui enregistre le cours et l’achèvement, et un petit site e-commerce à un seul prix et un seul entrepôt sont des endroits où la construction n’apporte rien qui vaille de payer l’écart entre une licence et un sprint. Nous ne vendons pas ces lignes comme « une solution provisoire, jusqu’à ce que vous soyez prêts pour le vrai système », parce que ce sont les vrais systèmes pour ces processus.

Nous vendons aussi ces produits, et ce n’est pas la promesse cachée qu’une construction viendra dans un an : WordPress reste une plateforme de contenu avec un thème que nous écrivons, non un thème tout fait sorti d’une boutique ; pour un petit site e-commerce aux processus standard, c’est nous-mêmes qui disons WooCommerce ; Moodle reste une plateforme de formation que nous configurons, migrons et habillons, non que nous inventons de zéro. Les prix de ces lignes sont sur les pages de service et, plus bas dans cet article, à l’endroit où il faut montrer que le plancher du sur-mesure n’est pas automatiquement la ligne la plus chère, et ici il suffit de dire que le produit reste un produit.

La conséquence, si vous commandez quand même une construction à cet endroit, n’est pas « un meilleur contrôle », mais une maintenance que vous ne partagez plus avec des milliers d’autres, parce que le correctif de sécurité d’un logiciel de messagerie, quelqu’un le publie pour tout le monde, alors que le correctif du vôtre, c’est vous qui le publiez, et cela ressemble à de la liberté, jusqu’à la deuxième nuit où il faut réparer ce que l’éditeur a déjà réparé dans son produit. Nous vendons cette liberté là où le processus la mérite, non là où une licence suffit, parce que, sinon, nous vous vendons un travail que, dans un an, vous détesterez comme un double coûteux.

La chose la plus honnête que nous puissions donc dire avant tout devis hors normes, c’est la liste des produits que nous vous recommanderions à la place : si le processus est la formation, commencez par Moodle, si le processus est le contenu, commencez par WordPress, si le processus est un petit site e-commerce, commencez par WooCommerce, et, si le processus est les factures et la tenue des comptes que la loi impose, commencez par la comptabilité que vous avez déjà, et seulement ensuite demandez si quelque chose de tout cela doit devenir un système à vous. Cette liste n’est pas un contrat de partenariat, c’est un test que nous appliquons contre nous-mêmes.

Quand le logiciel sur mesure se justifie

Le logiciel sur mesure se justifie quand le processus fait partie de votre compétitivité ou que les solutions toutes faites exigent trop de compromis, et le processus peut rester l’auxiliaire de ce que vous vendez et faire pourtant partie de ce test, parce que le test est le nombre de compromis, non le fait que vous vendiez du logiciel. Si le produit du marché commence à exiger que vous deveniez le client moyen, et que le client moyen n’est pas votre compétitivité, la construction est enfin un test que le processus a tenu, non l’envie d’un écran à soi.

L’intégration n’est pas ici un argument à elle seule, parce que les produits aussi ont des interfaces, et nous les branchons, et l’argument ne commence que lorsque l’interface ne suffit pas et que le processus exige que la vérité sur le stock, le prix ou le statut vive en un seul endroit que vous contrôlez. Le portail cartographique de Sadales tīkls, que nous avons construit sur Laravel et Leaflet, montre les coupures, la capacité disponible et les frais de raccordement, et ce n’est pas « une carte plus une extension », parce que le tarif et la capacité sont le processus de l’opérateur, non le champ d’un produit de cartes ; sur le portail Elektrum, la session SSO s’ajoute à chaque requête, avant que le configurateur Vue ne dessine, et ce n’est pas « un thème énergie sous WordPress », parce que la session est une part du service, non un décor.

La couleur, le logo et l’ordre des menus ne sont pas ce test, parce qu’on peut les faire dans un produit, et nous les faisons dans un produit : un thème Moodle à votre palette, un thème WordPress sans le superflu, un site e-commerce WooCommerce qui vous ressemble. Si la seule chose que l’on ne peut pas faire dans l’outil du marché, c’est « que cela nous ressemble », vous n’êtes pas arrivés au logiciel sur mesure, mais à un thème, et confondre les deux, c’est payer une construction là où un design suffit, puis s’étonner que la maintenance soit chère pour un système dont la seule différence est la couleur.

Nous ne disons pas non plus que chaque secteur exige automatiquement sa plateforme, parce que le nom du secteur n’est pas un test, et le test est de savoir si, dans votre entreprise, le processus de ce secteur est le même que celui que l’éditeur a déjà mis dans le paquet, ou s’il est votre manière de faire fonctionner le métier, et cette manière n’a pas le droit de s’acheter à côté. Si l’on peut l’acheter, achetez ; si l’on ne peut pas, alors il s’agit d’un système métier sur mesure, et seulement alors il vaut la peine de parler d’un atelier de cadrage, non d’un thème.

Le troisième chemin : un produit, avec notre code par-dessus

Entre le produit du marché et la construction à partir de zéro, il y a un troisième chemin, que nous vendons aussi et que les comparatifs laissent le plus souvent de côté : le produit reste un produit, et par-dessus nous écrivons ce que le produit ne fait pas, et ce n’est pas « un peu de logiciel sur mesure », mais la décision de laisser le cœur là où l’éditeur le maintient, et d’écrire seulement la couche qui est la vôtre. Le portail de services de Sadales tīkls tient sur October CMS, et les calculateurs, les calendriers et le signalement de panne sont un travail sur le produit, non un nouveau moteur de contenu ; dans une mise en place Moodle, nous vérifions d’abord si une extension d’évaluation ou de rapport existe déjà, et seulement ensuite nous écrivons la nôtre, parce que, sinon, nous vous vendons un double.

Si la question est un catalogue, des prix, une commande et une livraison, c’est le test de la boutique, et il est déjà écrit dans l’article sur le choix entre WooCommerce et Laravel, c’est pourquoi nous ne le réécrivons pas ici et ne le transformons pas en choix par défaut d’un système hors normes. Si la question porte sur un CRM, un ERP, un panneau interne ou un processus de secteur, restez ici, parce que la boutique est un cas du même test, non tout le contenu du choix.

Du côté de WordPress, le troisième chemin a l’air d’un refus, parce que nous ne posons pas de thèmes tout faits, ils apportent des fonctions qui deviennent un risque de sécurité, et nous construisons un thème propre, seulement avec ce qu’il faut, et c’est encore un produit : le rédacteur écrit dans WordPress, non dans un éditeur que nous aurions inventé, et les mises à jour viennent de WordPress, non d’une seule de nos versions. La différence entre cela et un système sur mesure, c’est que le processus de contenu tient dans le produit, mais que le processus du thème ne tient pas dans un thème ThemeForest, et les confondre, c’est soit poser un thème étranger puis s’étonner des extensions, soit construire son propre CMS pour un contenu pour lequel un CMS existe déjà.

Cette frontière est aussi l’endroit où nous disons non à une « petite reconstruction » qui, au troisième mois, est devenue le cœur, parce que, si les adaptations deviennent plus nombreuses que la configuration, si chaque mise à jour exige d’abord notre code, si le champ de l’éditeur n’est plus la vérité, vous n’êtes plus sur le troisième chemin. Vous êtes sur une construction qui se cache derrière le nom d’un produit, et alors le plus honnête est de nommer la construction et de la facturer comme une construction, parce que, sinon, vous payez un produit que l’on ne peut plus mettre à jour, et un système que l’on ne peut pas encore reprendre.

L’argent et le temps sont une forme, non une grille

Un système sur mesure, chez nous, se chiffre à partir de 8 000 €, et le cycle complet prend en général de 12 à 32 semaines, et c’est un « à partir de », non une facture, et 12 semaines ne sont pas les trois premiers mois dans lesquels nous promettons un MVP utilisable : le plancher est la construction la plus courte, le MVP est l’étape après laquelle on se sert déjà du système, et 32 semaines sont la borne haute d’un travail plus vaste, qui entre aussi dans ce que, dans la FAQ générale, nous appelons six à huit mois pour un grand système sur mesure. La page Laravel part du même plancher de 8 000 € et de 6 à 24 semaines, et ce n’est pas un logiciel sur mesure moins cher : c’est une page pour la personne qui sait déjà que le travail est du Laravel, non le test de savoir si le travail est une construction tout court.

Ces chiffres n’ont pas le droit de devenir la phrase « le logiciel sur mesure est le choix le plus cher », parce qu’une mise en place Moodle se chiffre à partir de 15 000 €, la version Pro du site e-commerce coûte 9 500 €, et les deux sont au-dessus du plancher du sur-mesure, parce que l’une est la mise en place d’un grand produit, l’autre un site e-commerce avec entrepôt et prix B2B. Comparer le plancher de 8 000 € au plancher Moodle comme « construction contre produit » est une arithmétique fausse, parce que l’on ne compare que les deux chemins d’un même processus, et, même alors, les deux côtés sont des planchers, non des totaux ; pour les travaux hors normes plus vastes, nous facturons en régie avec un plafond hebdomadaire, parce qu’un prix fixe y signifie d’ordinaire une majoration pour le risque ou un litige sur le périmètre, et le taux horaire est de 50 €.

L’abonnement contre la construction n’est pas non plus une formule où, après N années, un camp gagne automatiquement, et ce que nous voyons aussi dans les contrats privés reste simple : la facture SaaS peut monter avec le nombre d’utilisateurs ou l’indexation, les intégrations restent à votre charge, et un changement de fournisseur exige un plan de sortie, parce que les données sont chez lui. Ce n’est pas un pourcentage de la construction que nous citerions ici, parce que la note de bas de page derrière ces chiffres mène à des blogs de fournisseurs, et de tels chiffres, nous ne les écrivons pas, mais la forme demeure : l’abonnement est une ligne chaque année, la construction est un plancher plus la maintenance, et aucune des deux n’est sans ligne.

Le règlement sur les données, qui s’applique dans l’Union à partir du 12 septembre 2025, aide à extraire les données exportables d’un service en nuage et interdit au fournisseur de dresser des obstacles au changement de fournisseur, mais l’équivalence fonctionnelle, il la demande pour un service d’infrastructure à la demande (IaaS), non pour un CRM que vous « transféreriez » simplement, et le règlement 2023/2854 ne promet pas que le processus voyage avec le fichier. L’article 20 du règlement général sur la protection des données porte sur les données à caractère personnel que la personne concernée a fournies, non l’application, non votre configuration, non les règles métier, si bien que, si vous voulez un système que vous pouvez confier à un autre développeur, c’est le code source que nous remettons, non un export sorti du panneau d’un autre, et c’est aussi l’endroit où cette section s’arrête, parce que la phrase suivante serait déjà une grille, et nous n’en avons pas pour cette question.

Ce que nous ne disons pas quand nous parlons de logiciel sur mesure

Nous ne disons pas qu’un système à soi est toujours plus intelligent, que le produit du marché est pour ceux qui « n’ont pas encore grandi », ou qu’au bout de trois ans la construction s’est forcément amortie, parce qu’une telle courbe, sans votre processus, est une invention. Un article qui, après un début honnête, arrive quand même à la conclusion qu’il faut acheter une construction est allé trop loin, et nous l’avons assez vu pour nous arrêter ici, parce que l’honnêteté est une limite et qu’un test bref est le but.

Nous ne disons pas non plus que Laravel est la réponse à la question du produit du marché, parce que Laravel est la façon dont nous écrivons lorsque le test a déjà donné une construction, et vendre un framework à quelqu’un à qui il faut Moodle, c’est vendre un marteau à quelqu’un à qui il faut une étagère. Notre page Laravel part de 8 000 € et parle d’API, de files d’attente et de tests, mais cet article parle de savoir si vous avez seulement besoin de cette page, et les confondre, c’est choisir l’instrument avant d’avoir choisi le travail.

Nous ne disons pas non plus que l’atelier de cadrage est une façon cachée de vous faire entrer dans une construction, parce que le résultat de l’atelier est un plan, qui reste utile même si vous décidez de ne pas faire appel à nous, et parfois le plan dit : prenez le produit que vous avez déjà nommé, et nous le mettrons en place, ou un autre le mettra en place. Si cette phrase a pour vous l’air d’une affaire perdue, c’est parce que c’est une affaire perdue, et nous préférons perdre une construction où il faudrait écrire encore un CRM, plutôt que de gagner un client qui, un an plus tard, demande pourquoi il maintient un système auquel il aurait pu s’abonner.

Pour un marché public, ce test ne se transpose pas tel quel à une entreprise privée, parce que, dans la planification publique, la doctrine de la DINUM demande d’abord d’évaluer si une solution du marché existe déjà, et cela appartient au marché public, non à cette phrase, mais, du côté privé, appartiennent votre processus et notre grille. Les deux côtés peuvent arriver à la même réponse, et ils n’y arrivent pas parce que l’un serait la loi de l’autre.

Comment cette décision se prend chez nous

Le travail commence par un atelier de cadrage de deux à trois jours, où nous parcourons avec votre équipe les processus, les rôles des utilisateurs, les risques et le périmètre du MVP, et ce n’est pas une matinée de diapositives, mais un travail après lequel nous pouvons dire si le processus tient dans un outil du marché, s’il demande le troisième chemin, ou s’il est une construction. Si la réponse est un produit, l’atelier s’est remboursé avec cette phrase ; si la réponse est une construction, l’étape suivante n’est pas le code.

Avant le code de production, nous préparons en deux à trois semaines un prototype cliquable, parce qu’y changer d’avis coûte moins cher que dans un système achevé, et le prototype n’est pas « pour avoir de quoi montrer au conseil », mais l’endroit où vous voyez que la table de prix que vous avez nommée hier est en réalité une autre table, et où cette découverte coûte des jours, non des mois. Ce n’est qu’ensuite que commence le développement : dans les trois premiers mois, nous construisons un MVP que l’on peut réellement utiliser, puis nous l’étendons par itérations, en sprints de deux semaines, avec une démonstration à la fin de chacun.

À la fin, vous recevez le code source, la documentation et la configuration de l’infrastructure, et vous pouvez les confier à un autre développeur, et ce n’est pas la promesse que le transfert sera agréable, mais la promesse que vous n’êtes pas liés à notre compte. Sur les projets plus vastes, nous restons en régie avec un plafond hebdomadaire, et nous fixons pourtant la limite du MVP, parce que, sinon, « agile » devient un mot derrière lequel le périmètre disparaît, et, si après l’atelier vous prenez un autre chemin, le plan reste le vôtre, comme nous l’avons écrit sur la page de service, et cet article n’y change rien.

Avant de nous écrire, écrivez le processus sur une page, sans nom d’outil, et marquez les lignes que vous n’avez pas le droit de confier au cycle de versions d’un autre : si la page est vide ou n’y figure que « pour avoir un système à nous », vous avez besoin d’un produit, et nous le dirons aussi, mais, si la page porte un processus qu’un concurrent ne peut pas acheter comme un outil du marché, alors il vaut la peine de parler d’une construction. Écrivez-nous, si vous voulez que nous lisions cette page avec vous et disions de quel côté vous êtes, y compris lorsque la réponse est de prendre le produit que vous avez déjà nommé.