Ne rien construire, puis choisir

Cette page commence par les sept situations où la bonne décision est de ne rien construire, et ce n’est pas une précaution de style. Le conseil le plus rentable qu’un directeur de chantier puisse donner est celui qui annule le chantier. Il coûte une conversation, là où un projet mal fondé coûte des mois et se découvre au moment de la mise en service.

Les 7 seuils de non-construction

Chaque seuil porte un test observable par un tiers, vrai ou faux, jamais une impression. Il porte aussi ce qu’il faut faire à la place, tout de suite, et l’événement précis qui rouvre la question. Ne rien construire n’est jamais « attendre » : c’est faire autre chose, et savoir à quel signal on revient.

La procédure que le logiciel doit exécuter n'existe pas par écrit.

Le test qui tranche: Deux personnes qui exécutent la tâche aujourd'hui, interrogées séparément, en donnent deux descriptions qui diffèrent sur au moins une étape.
À faire à la place.: Écrire la procédure étape par étape, la faire relire par ceux qui l'exécutent, et la corriger jusqu'à ce que leurs deux descriptions concordent.
Quand reconsidérer.: Le jour où la procédure écrite est acceptée sans réserve par les personnes qui l'exécutent.

Le besoin est aujourd'hui tenu dans un tableur partagé, et le tableur ne casse pas.

Le test qui tranche: Aucune des trois ruptures du tableur n'est constatée : deux personnes ne modifient jamais la même ligne au même moment, personne n'a besoin de voir une partie du fichier sans voir le reste, et personne n'a jamais eu à savoir qui avait changé une valeur.
À faire à la place.: Garder le tableur, protéger les colonnes calculées, et noter la date de chacune des trois ruptures le jour où elle survient.
Quand reconsidérer.: Dès qu'une des trois ruptures est constatée et datée, car c'est elle et non le volume qui rend le tableur inadapté.

Un outil déjà disponible couvre le processus, mais son vocabulaire ou son apparence ne plaisent pas.

Le test qui tranche: Les trois opérations les plus fréquentes du processus sont toutes réalisables dans l'outil existant, et les écarts restants portent uniquement sur des libellés, des couleurs ou l'ordre des écrans.
À faire à la place.: Adopter l'outil, écrire la procédure interne qui traduit son vocabulaire dans celui de la maison, et former les utilisateurs.
Quand reconsidérer.: Le jour où une des trois opérations les plus fréquentes devient impossible dans l'outil, ou le jour où son fournisseur annonce son arrêt.

Le produit est décrit par un porteur enthousiaste, mais aucun utilisateur n'est nommé.

Le test qui tranche: Aucune personne nommée, extérieure à l'équipe qui construit, n'a accepté par écrit d'employer le produit à une date convenue.
À faire à la place.: Aller chercher cet engagement écrit auprès de trois personnes, et traiter chaque refus comme une information sur le besoin plutôt que sur la personne.
Quand reconsidérer.: Dès qu'une personne nommée, extérieure à l'équipe, a fixé par écrit la date à laquelle elle emploiera le produit.

Le produit repose sur une donnée que personne ne détient sous forme exploitable.

Le test qui tranche: Un extrait réel de la donnée nécessaire n'a pas pu être obtenu et ouvert, ou son détenteur n'a pas donné son accord écrit à son emploi.
À faire à la place.: Lancer un projet distinct de constitution de la donnée, avec sa propre date de fin, et traiter le logiciel comme sa suite et non comme son moyen.
Quand reconsidérer.: Le jour où un extrait réel de la donnée a été ouvert, compris et jugé suffisant pour la première fonctionnalité.

Le produit ne fonctionne qu'avec l'accès à un système tiers dont l'accès dépend d'une négociation en cours.

Le test qui tranche: Aucun identifiant d'essai n'a encore permis d'exécuter un appel réel vers ce système tiers et d'en lire la réponse.
À faire à la place.: Obtenir d'abord un accès d'essai et exécuter un seul appel réel, ce qui coûte quelques heures et remplace des semaines de suppositions sur le contrat.
Quand reconsidérer.: Le jour où un appel réel vers le système tiers a rendu une réponse lisible dans un environnement d'essai.

Le produit est finançable à la construction, mais pas à l'exploitation.

Le test qui tranche: La somme des abonnements mensuels indispensables au fonctionnement dépasse ce que le porteur peut payer douze mois de suite sans aucun revenu du produit.
À faire à la place.: Retirer des fonctionnalités jusqu'à ce que le coût mensuel tienne dans cette limite, ou renoncer, plutôt que de découvrir la coupure au huitième mois.
Quand reconsidérer.: Le jour où le périmètre a été réduit jusqu'à faire tenir le coût mensuel dans la limite, ou le jour où un revenu récurrent couvre ce coût.

Les 9 catégories auxquelles toute règle répond

Une règle technique répond à ces catégories, même par « aucune ». Répondre « aucune authentification, parce qu’il n’existe aucune ressource privée » est un enseignement ; laisser la case vide laisse croire à un oubli, et un agent comblera le vide tout seul.

Décision préalable : construire ou s'abstenir
Langage et cadre applicatif
Base de données
Authentification
Hébergement
Stockage de fichiers
Envoi de courriel
Surveillance des erreurs
Intégration continue

Quelle règle s’applique à votre projet

Deux questions suffisent : ce que vous construisez, et jusqu’où. Sur les 18 croisements possibles, 14 portent une règle et 4 sont écartés à dessein. Un croisement écarté ne décrit pas un produit rare : il décrit un produit mal qualifié, et le nommer évite d’aller chercher une règle qui n’existe pas.

Croisements entre la nature du produit et son ampleur
Nature du produit	Prototype	Produit	Plateforme
Site vitrine	Règle	Règle	Écarté
Application web	Règle	Règle	Règle
Application mobile	Règle	Règle	Écarté
Logiciel en service, multi-organisations	Écarté	Règle	Règle
Automatisation interne	Règle	Règle	Écarté
Service applicatif	Règle	Règle	Règle

Pourquoi ces 4 croisements sont écartés

Site vitrine · Plateforme
Une vitrine cesse d'être une vitrine dès que plusieurs organisations y publient leur propre contenu sous leur propre responsabilité.
La règle à appliquer à la place. Requalifier le produit en SaaS multi-locataire d'ampleur plateforme, car la vraie question devient l'isolation entre éditeurs et non la mise en page.
Application mobile · Plateforme
L'ampleur plateforme porte sur le service qui alimente l'application installée, jamais sur l'application elle-même, qui reste un client.
La règle à appliquer à la place. Appliquer la règle SaaS multi-locataire plateforme au service, et la règle application mobile produit au client installé sur l'appareil.
Logiciel en service, multi-organisations · Prototype
Un prototype multi-locataire prouve la mécanique d'isolation avant d'avoir prouvé le besoin, donc il coûte le prix du plus difficile pour répondre à la question la plus facile.
La règle à appliquer à la place. Appliquer la règle application web prototype chez un premier client, puis la règle SaaS multi-locataire produit le jour où un deuxième client payant exige la même fonctionnalité.
Automatisation interne · Plateforme
Une automatisation qui atteint cette ampleur a des utilisateurs qui ne sont pas ses auteurs, ce qui la fait changer de nature et non seulement de taille.
La règle à appliquer à la place. Requalifier en application web ou en SaaS multi-locataire selon que les utilisateurs appartiennent ou non à la même organisation, avant tout choix technique.

Les 14 règles de choix

Chaque choix porte sa raison, en une phrase vérifiable. Jamais « c’est moderne », jamais « c’est populaire » : une raison qui ne se vérifie pas est un goût, et un goût ne se défend pas devant quelqu’un qui paie.

Site vitrine · Prototype

Décision préalable : construire ou s'abstenir: Une seule page publiée, avec un formulaire de contact ; si l'objectif tient dans un document partagé ou un formulaire hébergé, on ne construit rien.; Le seul résultat mesurable attendu à ce stade est le nombre de personnes qui laissent un moyen de les rappeler, et ce nombre s'obtient sans écrire une ligne de code.
Langage et cadre applicatif: Pages HTML et CSS produites à la construction par un générateur de site statique, sans cadre applicatif exécuté dans le navigateur.; La page n'a aucun état à conserver entre deux clics, donc tout script chargé pour l'afficher est un coût de téléchargement sans contrepartie fonctionnelle.
Base de données: Aucune base de données ; les soumissions du formulaire partent vers un service de collecte ou une feuille de calcul.; Une base de données ne se justifie que lorsqu'une donnée doit être relue et modifiée par le produit lui-même, ce qui n'arrive jamais dans une vitrine.
Authentification: Aucune authentification de visiteur ; seul l'accès à l'outil de publication est protégé, avec deux facteurs.; Il n'existe aucune ressource privée à protéger côté visiteur, et ajouter un compte créerait une surface d'attaque pour une fonctionnalité que personne ne demande.
Hébergement: Hébergement de fichiers statiques derrière un réseau de diffusion, certificat TLS renouvelé automatiquement, aucun serveur applicatif.; Le contenu est identique pour tous les visiteurs, donc il peut être servi depuis un cache proche du visiteur sans exécuter le moindre processus.
Stockage de fichiers: Images optimisées versionnées avec le site ; aucun téléversement par un visiteur.; Autoriser un téléversement obligerait à contrôler le type, la taille et le contenu du fichier, trois vérifications qu'aucune vitrine ne justifie.
Envoi de courriel: Un service d'envoi transactionnel, domaine authentifié par SPF, DKIM et DMARC, pour la seule notification de formulaire.; Un message envoyé depuis un domaine non authentifié arrive en indésirable, et un prospect perdu de cette façon ne se sait jamais perdu.
Surveillance des erreurs: Aucun outil dédié ; un envoi de test hebdomadaire du formulaire et une vérification des liens, consignés dans le journal de direction.; Sur une page sans exécution côté serveur, la seule panne possible est le formulaire, et un test hebdomadaire la détecte au même coût qu'un outil de surveillance.
Intégration continue: Publication automatique à chaque modification de la branche principale, précédée du contrôle du poids de la page et de la recherche de liens morts.; Ces deux contrôles couvrent les seuls défauts que la page peut porter, et un contrôle laissé à la mémoire humaine cesse d'être fait dès la première semaine chargée.
Budget de données et réseau: Budget arrêté avant d'écrire la page : trois cents kilo-octets pour l'ensemble du premier affichage, une seule fonte, images au format WebP servies en deux largeurs.; Le budget se mesure sur l'appareil et le forfait de données les plus modestes recensés pendant la découverte, et une page qui les dépasse n'est pas lue quelle que soit sa qualité.
Gestion du contenu: Textes et images dans des fichiers versionnés du dépôt ; aucun gestionnaire de contenu.; Un gestionnaire de contenu ne se justifie qu'à partir du moment où une personne non technique publie sans passer par vous, ce qui n'est pas encore le cas.

Ce qu’on écarte ici

Un cadre de composants exécuté dans le navigateur : il fait télécharger un script pour produire un rendu que le serveur peut livrer déjà écrit.
Un gestionnaire de contenu hébergé : il facture un abonnement mensuel avant qu'un seul visiteur ait laissé son courriel.
Les animations au défilement : elles imposent une bibliothèque, allongent le premier affichage, et leur retrait se teste en une heure sans changer le nombre de formulaires remplis.
Un outil complet de mesure d'audience : le décompte des soumissions répond à la seule question posée ici, sans script tiers ni bandeau de consentement à gérer.
Un test visuel anti-robot : il charge un script tiers lourd et bloque les visiteurs sur connexion lente, alors qu'un champ piège arrête les mêmes envois automatisés.

Site vitrine · Produit

Décision préalable : construire ou s'abstenir: On passe du prototype au produit uniquement si une personne non technique doit publier sans vous au moins une fois par mois.; Toute la différence de coût entre les deux tient dans le gestionnaire de contenu et sa formation, dépense sans objet tant que vous restez le seul à publier.
Langage et cadre applicatif: Générateur de site statique produisant des pages pré-rendues, avec des îlots de script uniquement là où une interaction l'exige.; Une page pré-rendue s'affiche même quand le script échoue à se charger, ce qui est le cas le plus fréquent sur une connexion qui coupe en cours de route.
Base de données: Aucune base applicative ; le contenu structuré est lu au moment de la construction, jamais à chaque visite.; Lire le contenu à la construction supprime la panne la plus fréquente d'une vitrine, qui est de tomber parce que sa source de contenu est indisponible.
Authentification: Aucune authentification de visiteur ; comptes nominatifs sur le gestionnaire de contenu, deux facteurs obligatoires, retrait immédiat au départ d'un contributeur.; La seule prise réelle sur une vitrine est la publication d'un contenu frauduleux par un compte d'édition volé ou oublié.
Hébergement: Fichiers statiques servis par un réseau de diffusion multi-région, avec un environnement de prévisualisation distinct pour chaque proposition de modification.; Une prévisualisation par proposition permet au contributeur de voir sa page avant publication, seul moyen de supprimer les corrections faites en direct sur le site public.
Stockage de fichiers: Médiathèque du gestionnaire de contenu, images retaillées à la construction en trois largeurs et converties en WebP.; Un contributeur non technique téléverse la photo telle que son appareil la produit, et sans retaille automatique cette seule image dépasse le budget de la page entière.
Envoi de courriel: Service transactionnel avec domaine authentifié ; le formulaire est protégé par un champ piège et une limitation par adresse, sans test visuel.; Un champ piège et une limitation de fréquence arrêtent les mêmes envois automatisés qu'un test visuel, sans imposer de téléchargement au visiteur sur connexion lente.
Surveillance des erreurs: Surveillance externe de disponibilité toutes les cinq minutes et alerte sur échec d'envoi du formulaire, adressée à une personne nommée.; Un formulaire cassé ne produit aucune plainte parce que le visiteur croit avoir envoyé son message, donc seule une alerte automatique révèle la panne.
Intégration continue: À chaque proposition : poids de page, liens morts, balisage structuré, navigation au clavier et présence d'une description sur chaque page.; Ces cinq contrôles couvrent les défauts qu'un contributeur non technique introduit sans le savoir et qu'il ne saurait pas diagnostiquer après coup.
Budget de données et réseau: Cinq cents kilo-octets au premier affichage, fontes du système par défaut, aucune vidéo lue automatiquement, cartes remplacées par une image et un lien.; Une carte interactive et une vidéo automatique consomment à elles seules plus de données que le reste du site, pour un service que l'image et le lien rendent aussi bien.
Gestion du contenu: Gestionnaire de contenu externe avec un modèle de page contraint, dont les champs titre, description et image de partage sont obligatoires.; Un modèle qui impose ces trois champs supprime la page publiée sans description, seul défaut qu'un contributeur non technique ne peut ni voir ni diagnostiquer.
Sauvegarde et restauration: Le dépôt sauvegarde le contenu versionné ; export automatisé mensuel du gestionnaire de contenu externe, conservé hors de ce fournisseur.; Un contenu qui n'existe que chez un fournisseur disparaît avec le compte, alors qu'un export mensuel se restaure en une heure sur un autre outil.

Ce qu’on écarte ici

Un rendu par serveur à chaque visite : il fait dépendre l'affichage de la disponibilité de la base, alors que le contenu ne change que quelques fois par mois.
Un gestionnaire de contenu auto-hébergé : il ajoute des mises à jour de sécurité mensuelles à la charge de quelqu'un qui n'est pas administrateur système.
Une application à page unique : elle affiche un écran vide tant que le script n'est pas chargé, ce que les moteurs de recherche et les connexions lentes traitent de la même façon.
Un espace membre : tant qu'aucun contenu n'est réservé, il n'apporte qu'une base de mots de passe à protéger.
Une traduction automatique du site : elle produit un texte dont personne n'assume la responsabilité juridique, alors qu'une vitrine engage l'entreprise.

Application web · Prototype

Décision préalable : construire ou s'abstenir: On construit seulement si le parcours à prouver ne peut pas être joué à la main pendant deux semaines avec de vrais utilisateurs et un tableur partagé.; Jouer le parcours à la main révèle les étapes que personne n'avait décrites, et ces étapes coûtent dix fois plus cher à découvrir une fois le code écrit.
Langage et cadre applicatif: Un seul langage typé du navigateur au serveur, avec un cadre applicatif qui rend les pages côté serveur par défaut.; Un seul langage supprime la traduction manuelle des structures de données entre les deux côtés, qui est la source d'erreur la plus fréquente quand une seule personne dirige le chantier.
Base de données: Base relationnelle gérée, schéma décrit en migrations versionnées dès la première table.; Même un prototype accumule des données réelles que l'on ne veut pas perdre, et une migration versionnée est le seul moyen de rejouer le schéma à l'identique ailleurs.
Authentification: Fournisseur d'authentification géré, connexion par courriel et lien à usage unique, aucun mot de passe stocké par vous.; Écrire soi-même le stockage d'un mot de passe expose à une erreur de salage ou de comparaison qu'un apprenant ne peut pas détecter en relisant le code.
Hébergement: Plateforme d'exécution gérée, avec un environnement d'essai et un environnement de production séparés dès le premier jour.; Séparer les deux environnements après coup exige de démêler des données de test mélangées aux données réelles, travail que personne ne fait jamais.
Stockage de fichiers: Stockage objet séparé de la base, accès par adresses signées à durée limitée, jamais de fichier dans une colonne.; Un fichier rangé dans la base fait grossir chaque sauvegarde de sa taille et rend toute restauration plus lente que la panne qu'elle répare.
Envoi de courriel: Service transactionnel, domaine authentifié, et blocage matériel des envois hors production vers une boîte de capture.; Un environnement d'essai qui écrit à de vraies adresses finit toujours par envoyer un message de test à un client, incident qui coûte une relation entière.
Surveillance des erreurs: Collecte des erreurs dès le premier déploiement, avec alerte immédiate sur toute erreur jamais vue auparavant.; Sur un prototype l'utilisateur ne signale pas les pannes, il part, et la seule trace de son départ est l'erreur enregistrée à cet instant.
Intégration continue: À chaque proposition de modification : compilation, contrôle de style, tests automatisés, et refus de fusion si l'un des trois échoue.; Un contrôle qui ne s'exécute pas automatiquement à chaque proposition finit par ne plus s'exécuter du tout, et son absence ne se remarque qu'au premier incident.
Budget de données et réseau: Premier écran rendu par le serveur et budget de trois cents kilo-octets de script exécuté, mesuré à chaque construction.; Un prototype se juge sur ce que l'utilisateur en fait, et un écran qui met dix secondes à répondre sur son réseau produit un abandon que l'on lirait à tort comme un rejet du produit.
Gestion des secrets: Variables d'environnement du fournisseur d'hébergement, jamais dans le dépôt, et rotation à chaque départ d'une personne ayant eu accès.; Une clé écrite une fois dans le dépôt reste lisible dans l'historique après la suppression du fichier, donc supprimer ne révoque rien.

Ce qu’on écarte ici

Le découpage en services séparés : il transforme des appels de fonction en appels réseau susceptibles d'échouer, avant même qu'une seule fonctionnalité soit prouvée.
Un orchestrateur de conteneurs : il demande une compétence d'exploitation à temps plein pour un produit qui n'a pas encore d'utilisateur.
Un cache distribué : il n'a rien à accélérer tant qu'aucune requête n'a été mesurée comme lente.
Une isolation multi-locataire : elle coûte le prix de la partie la plus difficile pour répondre à la question la plus facile, alors qu'un seul client est concerné.
Une application mobile en parallèle : elle double le travail de construction avant que le parcours ait été validé une seule fois sur un écran.

Application web · Produit

Décision préalable : construire ou s'abstenir: On passe du prototype au produit le jour où une personne extérieure à l'équipe emploie l'application dans son travail sans qu'on la lui rappelle.; Cet usage spontané est le seul signe qui distingue un produit d'une démonstration, et il est observable dans les journaux sans demander l'avis de personne.
Langage et cadre applicatif: Le même langage typé qu'au prototype, en un seul programme déployable, avec des modules séparés par domaine métier.; Garder un seul programme déployable permet de modifier deux domaines dans une même livraison, ce qui reste le cas tant qu'une seule équipe livre.
Base de données: Base relationnelle gérée avec contraintes d'intégrité déclarées dans le moteur, index posés d'après les requêtes réellement mesurées.; Une contrainte déclarée dans le moteur reste vraie même quand un script d'urgence écrit directement dans la table, ce qui arrive au premier incident.
Authentification: Fournisseur géré, sessions côté serveur, deuxième facteur proposé, rôles vérifiés côté serveur à chaque requête et non seulement dans l'interface.; Un rôle vérifié uniquement dans l'interface se contourne en appelant directement l'adresse de l'interface de programmation, ce qu'un navigateur suffit à faire.
Hébergement: Plateforme gérée, région d'exécution choisie d'après la latence mesurée depuis les villes des utilisateurs recensés, et trois environnements.; La région se choisit sur une latence mesurée et non sur un prix affiché, parce qu'un aller-retour supplémentaire de deux cents millisecondes se voit à chaque clic.
Stockage de fichiers: Stockage objet, téléversement direct par adresse signée, contrôle du type réel du fichier côté serveur et plafond de taille.; Faire transiter le fichier par le serveur applicatif immobilise sa mémoire pendant tout le téléversement et le fait tomber au-delà de quelques envois simultanés.
Envoi de courriel: Service transactionnel avec domaine authentifié, gabarits versionnés dans le dépôt, journal des envois et gestion des adresses en échec.; Sans traitement des adresses en échec, la réputation du domaine se dégrade et les messages cessent d'arriver à tous les autres destinataires.
Surveillance des erreurs: Collecte des erreurs avec version déployée, identifiant de requête et parcours de l'utilisateur, plus une alerte sur le taux d'erreur par écran.; Une erreur sans la version déployée oblige à deviner quelle livraison l'a introduite, ce qui transforme une correction de dix minutes en enquête d'une journée.
Intégration continue: Compilation, style, tests unitaires, plus un test de bout en bout du parcours qui rapporte de l'argent ou fait le service, exécuté avant chaque mise en production.; Le parcours qui rapporte est le seul dont la panne se paie immédiatement, donc c'est le seul qui justifie le coût d'un test de bout en bout à ce stade.
Budget de données et réseau: Deux cents kilo-octets de script exécuté par écran, premier écran rendu par le serveur, listes paginées à vingt éléments, images à la taille d'affichage.; Le premier écran doit rester utilisable sur le réseau le plus lent recensé pendant la découverte, faute de quoi la fonctionnalité existe sans jamais être atteinte.
Gestion des secrets: Coffre du fournisseur ou gestionnaire de secrets dédié, accès nominatif tracé, rotation planifiée et rotation immédiate sur soupçon.; Une clé dont on ignore qui l'a lue ne peut pas être déclarée sûre après un départ, donc la traçabilité de l'accès est ce qui rend la rotation décidable.
Sauvegarde et restauration: Sauvegarde quotidienne avec restauration à un instant donné, et une restauration réelle exécutée et chronométrée avant la mise en production.; Une sauvegarde jamais restaurée n'est pas une sauvegarde, et seule la restauration chronométrée donne le délai de reprise que l'on pourra annoncer.
Journalisation et traçabilité: Journal structuré avec un identifiant de requête propagé de bout en bout, sans donnée personnelle en clair, conservé une durée écrite.; Un identifiant de requête propagé permet de suivre une plainte précise d'un utilisateur jusqu'à la ligne fautive sans lire les journaux des autres.

Ce qu’on écarte ici

Le passage en services séparés : il se justifie quand deux équipes déploient à des rythmes différents, condition qui n'est pas remplie ici.
Une interface de programmation publique : elle crée un contrat que l'on ne peut plus casser, alors qu'aucun consommateur externe ne s'est engagé.
Un réplica de lecture : il ne se justifie qu'une fois qu'une lecture mesurée gêne les écritures, mesure qui n'a pas encore été faite.
Une application à page unique complète : elle déplace le rendu sur l'appareil le moins puissant de la chaîne, alors que le serveur peut le faire une fois pour tous.
Un système de fonctionnalités activables maison : la même souplesse s'obtient par une colonne de configuration, sans le code d'administration qui va avec.

Application web · Plateforme

Décision préalable : construire ou s'abstenir: On ne passe à l'ampleur plateforme qu'à partir du moment où deux équipes distinctes doivent livrer à des rythmes différents sur le même produit.; Tout le surcoût de cette ampleur sert à découpler des calendriers de livraison, donc il n'a aucune contrepartie tant qu'il n'existe qu'un seul calendrier.
Langage et cadre applicatif: Programme unique découpé en modules aux frontières explicites, et extraction d'un service séparé seulement quand un module a son propre rythme de livraison mesuré.; Extraire un service transforme un appel de fonction en appel réseau susceptible d'échouer, coût que seule une contrainte de calendrier différent justifie.
Base de données: Base relationnelle principale, réplicas de lecture pour les rapports, et migrations en deux temps qui ajoutent avant de retirer.; Une migration qui supprime une colonne encore lue par la version déployée provoque une panne dont le retour en arrière du code ne suffit pas à sortir.
Authentification: Fournisseur géré avec jetons de courte durée, connexion déléguée à l'annuaire du client quand il en a un, et journal des connexions conservé.; Déléguer la connexion à l'annuaire du client fait disparaître ses comptes le jour où il retire un salarié, ce qu'aucune procédure manuelle ne garantit.
Hébergement: Plateforme gérée avec déploiement progressif et retour en arrière en une commande, environnement de pré-production identique à la production.; Un déploiement progressif limite la population exposée à une régression au premier pourcentage de trafic, ce qui rend le retour en arrière indolore.
Stockage de fichiers: Stockage objet avec cycle de vie déclaré, classes de stockage économiques pour les fichiers anciens, et suppression effective à échéance.; Sans règle de cycle de vie, la facture de stockage croît indéfiniment pour des fichiers que plus personne ne consulte et que la loi oblige parfois à effacer.
Envoi de courriel: Service transactionnel séparé des envois de masse, domaines d'envoi distincts, et préférences de réception par utilisateur.; Un envoi de masse mal reçu dégrade la réputation du domaine, et séparer les domaines empêche cette dégradation d'atteindre les messages de connexion.
Surveillance des erreurs: Collecte des erreurs reliée aux traces réparties, budget d'erreur écrit par service, et alerte fondée sur la dégradation du parcours et non sur le volume.; Une alerte fondée sur le volume se déclenche à chaque pic de trafic normal, ce qui apprend à l'équipe à ignorer les alertes.
Intégration continue: Tests unitaires, tests de bout en bout des parcours critiques, contrôle de migration en deux temps et refus de fusion sur baisse de couverture des modules critiques.; Le contrôle automatique de la migration est le seul moyen d'empêcher une suppression de colonne prématurée, erreur qu'aucune relecture humaine ne rattrape.
Budget de données et réseau: Budget de données mesuré par écran à chaque livraison, mise en cache agressive des ressources versionnées, et refus de fusion au dépassement.; Le poids d'une application ne se dégrade jamais d'un coup mais par ajouts successifs, donc seul un contrôle à chaque livraison le maintient.
Ordonnancement des traitements: File de travaux durable, tâches idempotentes portant une clé, réessai à délai croissant et file d'échecs consultable.; Sans clé d'idempotence, un réessai après une coupure réseau rejoue une action déjà effectuée et produit un doublon que personne ne détecte.
Quotas et limitation de débit: Limitation par compte et par organisation, jamais par adresse réseau seule, avec en-têtes indiquant le quota restant.; Une limite par adresse punit tout un bureau ou tout un réseau mobile partagé derrière une seule sortie, situation courante chez les utilisateurs visés.
Gestion des secrets: Gestionnaire de secrets dédié, aucun secret durable dans les variables d'environnement, identités de charge de travail pour les accès entre services.; Une identité de charge de travail délivre un jeton de quelques minutes, donc son vol ne donne pas le même accès permanent qu'une clé recopiée.
Sauvegarde et restauration: Sauvegarde à un instant donné, copie dans une seconde région, et exercice de restauration trimestriel dont le résultat est écrit.; Une sauvegarde stockée chez le même fournisseur et dans la même région disparaît avec l'incident qu'elle devait couvrir.
Journalisation et traçabilité: Journal structuré, traces réparties reliant les modules, et piste d'audit distincte en ajout seul pour les actions sensibles.; Un journal technique se purge et se réécrit, donc il ne peut pas servir de preuve, ce que seule une piste en ajout seul permet.
Mesure de l'usage: Compteurs d'usage reconstruits à partir d'un journal d'événements, jamais à partir d'un compteur incrémenté en place.; Un compteur incrémenté ne se recalcule pas après un incident, alors qu'un journal d'événements se rejoue et rend le chiffre défendable.

Ce qu’on écarte ici

Une base de données par service : elle rend impossible toute écriture transactionnelle entre deux domaines, contrainte que peu d'équipes savent porter.
Un maillage de services : il ajoute une couche d'exploitation dont le diagnostic dépasse la compétence de l'équipe qui la déploierait.
Une réécriture complète pour changer de cadre applicatif : elle immobilise la livraison pendant des mois sans ajouter une fonctionnalité visible.
Une source d'événements généralisée : elle impose de reconstruire l'état à chaque lecture, prix qui ne se justifie que là où l'historique complet est exigé.
Un cache applicatif avant mesure : il masque le vrai problème de requête et rend la panne plus difficile à comprendre quand il expire.

Application mobile · Prototype

Décision préalable : construire ou s'abstenir: On ne construit une application installable que si une capacité de l'appareil est indispensable au parcours : appareil photo, position, notification poussée ou usage hors ligne.; Le passage par une boutique ajoute un délai de validation à chaque correction, coût permanent que seul un accès matériel réellement nécessaire justifie.
Langage et cadre applicatif: Un seul code pour les deux systèmes d'exploitation, choisi d'après la disponibilité des bibliothèques natives nécessaires au parcours à prouver.; La disponibilité d'une bibliothèque native se vérifie en une demi-journée et détermine à elle seule si le parcours est réalisable sans écrire de code natif.
Base de données: Base relationnelle gérée côté serveur, et base locale légère sur l'appareil pour les seules données affichées au démarrage.; Afficher un écran rempli avant la première réponse du réseau est la seule façon de rendre l'application utilisable quand la connexion met plusieurs secondes à répondre.
Authentification: Fournisseur géré, jeton conservé dans le magasin sécurisé du système d'exploitation, jamais dans les préférences de l'application.; Les préférences d'une application sont incluses dans la sauvegarde du téléphone et lisibles depuis cette sauvegarde, ce qui n'est pas le cas du magasin sécurisé.
Hébergement: Le même service que pour une application web prototype, avec une adresse de service distincte pour les versions d'essai.; Une version d'essai installée sur le téléphone d'un testeur continue d'appeler l'adresse compilée dans le paquet, donc elle doit pointer ailleurs que la production.
Stockage de fichiers: Stockage objet, photos redimensionnées et compressées sur l'appareil avant envoi, envoi repris automatiquement après coupure.; Une photo envoyée telle que l'appareil la produit consomme à elle seule plus de données que le reste d'une session complète d'utilisation.
Envoi de courriel: Service transactionnel pour les seuls messages de compte, avec une variante par message court quand le courriel n'est pas relevé par les utilisateurs recensés.; Le canal de confirmation se choisit d'après celui que les utilisateurs recensés relèvent effectivement, sans quoi les comptes créés restent non confirmés.
Surveillance des erreurs: Collecte des plantages avec modèle d'appareil, version du système, version de l'application et quantité de mémoire disponible.; Sans le modèle d'appareil dans le rapport, une panne qui ne touche qu'une gamme d'appareils d'entrée de gamme reste invisible dans les statistiques globales.
Intégration continue: Construction automatique du paquet à chaque proposition, contrôle de sa taille, et distribution aux testeurs sans intervention manuelle.; Une construction faite à la main sur le poste du constructeur produit un paquet que personne ne peut reproduire, donc aucune régression n'est traçable.
Distribution de l'application: Android d'abord, diffusion par paquet signé à une liste de testeurs nommés, dépôt en boutique seulement après validation du parcours.; Le système visé en premier se décide d'après le parc d'appareils des utilisateurs recensés pendant la découverte, et non d'après l'appareil du constructeur.
Budget de données et réseau: Taille du paquet installable plafonnée et vérifiée à chaque construction, images incluses au strict nécessaire, aucune police embarquée.; Un utilisateur qui paie ses données à l'unité renonce à l'installation au-delà du plafond fixé, et ce renoncement ne laisse aucune trace exploitable.
Fonctionnement hors ligne: Lecture de la dernière réponse mise en cache et message explicite hors connexion ; aucune synchronisation bidirectionnelle à ce stade.; Une synchronisation bidirectionnelle exige une règle écrite de résolution des conflits, décision que l'on ne prend pas avant de savoir quelles données sont modifiées hors ligne.

Ce qu’on écarte ici

Le développement natif séparé pour deux systèmes : il double le travail avant que le parcours ait été validé une seule fois.
La publication simultanée sur les deux boutiques : elle double le délai de validation à chaque correction pendant la phase où l'on corrige le plus.
Une synchronisation hors ligne complète : elle impose de trancher les conflits avant de savoir quelles données seront réellement modifiées sans réseau.
Un système de conception maison : les composants fournis par le cadre suffisent tant que l'application n'a pas prouvé qu'elle sera maintenue.
Les notifications poussées dès le premier jour : elles exigent une gestion du consentement et des jetons expirés, travail sans objet tant qu'aucun message utile n'existe.

Application mobile · Produit

Décision préalable : construire ou s'abstenir: On passe au produit quand des utilisateurs qui ne connaissent pas le constructeur installent l'application et reviennent une deuxième semaine.; Le retour en deuxième semaine est le premier signal qui ne peut pas être produit par la politesse d'un proche, contrairement à une première installation.
Langage et cadre applicatif: Le même code unique qu'au prototype, avec les seuls modules natifs que le parcours impose, chacun justifié par écrit dans la décision d'architecture.; Chaque module natif ajouté doit être maintenu à chaque montée de version du système, donc son coût se paie tous les ans et non une seule fois.
Base de données: Base locale faisant autorité pour la lecture, base relationnelle gérée côté serveur faisant autorité pour l'écriture validée.; Désigner une seule autorité par sens de circulation supprime la question sans réponse de savoir laquelle des deux copies a raison.
Authentification: Fournisseur géré, jeton de courte durée dans le magasin sécurisé, jeton de renouvellement révocable par appareil et déconnexion à distance.; Un téléphone perdu reste connecté indéfiniment tant qu'il n'existe pas de révocation par appareil, et l'utilisateur ne peut alors rien faire d'autre que changer son mot de passe.
Hébergement: Service géré avec versionnement de l'interface appelée par l'application, et maintien des anciennes versions tant que des appareils les appellent.; Un utilisateur qui ne met pas son application à jour continue d'appeler l'ancienne interface, et couper celle-ci le prive du service sans qu'il comprenne pourquoi.
Stockage de fichiers: Stockage objet, compression sur l'appareil, envoi différé quand la connexion est absente et reprise à l'octet près après coupure.; Un envoi qui recommence de zéro après chaque coupure ne se termine jamais sur une connexion instable, et l'utilisateur abandonne sa saisie.
Envoi de courriel: Service transactionnel pour les messages de compte et les reçus, message court pour les confirmations urgentes, préférences modifiables dans l'application.; Un reçu envoyé par un canal que l'utilisateur ne relève pas produit une réclamation que le support devra traiter à la main, une par transaction.
Surveillance des erreurs: Collecte des plantages et des erreurs non fatales, taux de plantage suivi par version et par gamme d'appareil, blocage du déploiement au-delà d'un seuil écrit.; Sans seuil écrit avant la livraison, la décision d'arrêter un déploiement se prend sous pression et se prend donc trop tard.
Intégration continue: Construction signée reproductible, tests automatisés du parcours principal sur un appareil d'entrée de gamme, et publication en boutique déclenchée par étiquette.; Un test qui ne s'exécute que sur un appareil récent laisse passer les lenteurs et les manques de mémoire qui touchent les appareils réellement employés.
Distribution de l'application: Boutique pour le paquet natif, plus un canal de mise à jour du code non natif permettant de corriger sans repasser par la validation.; Un correctif immobilisé plusieurs jours en validation laisse le défaut en production pendant tout ce délai, alors que la correction est prête.
Budget de données et réseau: Toute liste paginée, images servies à la taille d'affichage, et un mode économie de données activable qui supprime les images et diffère les envois.; Un mode économie de données rend l'application utilisable en fin de forfait, moment où l'utilisateur désinstalle faute de pouvoir s'en servir.
Fonctionnement hors ligne: Base locale faisant autorité en lecture, file d'écritures portant une clé d'idempotence, et règle de conflit écrite dans la spécification fonctionnelle.; Sans règle écrite, le conflit est tranché par l'ordre d'arrivée sur le serveur, et l'utilisateur perd une saisie sans jamais en être informé.
Gestion des secrets: Aucune clé de service dans le paquet installable ; l'appareil ne détient qu'un jeton personnel de courte durée.; Un paquet installable se décompresse et se lit, donc toute clé qu'il contient est publique dès la première installation.
Sauvegarde et restauration: Sauvegarde côté serveur avec restauration à un instant donné ; la base locale de l'appareil est traitée comme un cache reconstructible.; Traiter la base locale comme reconstructible autorise à l'effacer pour sortir d'un état corrompu, sans perdre une donnée que le serveur ne détiendrait pas.

Ce qu’on écarte ici

Une réécriture en natif pour la performance : elle se décide sur une mesure faite sur les appareils réellement employés, mesure qui n'a pas été produite.
Une bibliothèque d'animations lourde : elle consomme la mémoire des appareils d'entrée de gamme, où elle produit des saccades au lieu de fluidité.
Le stockage de données personnelles sur l'appareil sans chiffrement : un téléphone se prête et se revend, contrairement à un serveur.
Une carte interactive intégrée : elle télécharge des tuiles à chaque déplacement, coût de données que peu de parcours justifient.
Un rythme de publication hebdomadaire en boutique : chaque version impose une validation, et l'utilisateur ne met pas à jour aussi souvent.

Logiciel en service, multi-organisations · Produit

Décision préalable : construire ou s'abstenir: On ne construit un produit multi-locataire qu'à partir de deux organisations payantes qui exigent la même fonctionnalité ; en deçà, on applique la règle application web produit.; La deuxième organisation est celle qui révèle ce qui doit être séparé, et anticiper cette séparation sur un seul client produit une abstraction que le deuxième contredit.
Langage et cadre applicatif: Un seul langage typé, un seul programme déployable, et l'identifiant d'organisation porté par le contexte de la requête plutôt que passé de fonction en fonction.; Un identifiant transporté à la main finit par être oublié dans un appel, alors qu'un contexte de requête rend cet oubli visible à la compilation.
Base de données: Base relationnelle unique, colonne d'organisation obligatoire sur chaque table portant des données de client, contrainte de clé étrangère vers la table des organisations.; Une colonne d'organisation nulle est une ligne qui appartient à tout le monde, donc la contrainte est ce qui empêche la fuite plutôt que la vigilance.
Isolation des locataires: Sécurité au niveau des lignes activée dans le moteur, et contrôle automatique refusant toute requête administrative sans filtre d'organisation.; Un filtre oublié dans une seule requête suffit à montrer les données d'un client à un autre, et seule une vérification automatique sur toutes les requêtes le garantit.
Authentification: Fournisseur géré, appartenance à une organisation portée par le jeton, rôles vérifiés côté serveur, et invitation nominative plutôt que création libre de compte.; Une création libre de compte permet à un inconnu d'atterrir dans l'organisation d'un client en devinant le nom de domaine employé au moment de l'inscription.
Hébergement: Plateforme gérée, trois environnements, et déploiement identique pour tous les locataires à partir d'une seule image.; Déployer une version différente par locataire fait diverger silencieusement les correctifs et rend impossible de dire ce qui tourne chez qui.
Stockage de fichiers: Stockage objet avec préfixe par organisation, adresses signées de courte durée, et refus au serveur de toute lecture hors du préfixe de l'appelant.; Un identifiant de fichier deviné dans une adresse non signée donne accès au document d'un autre client sans qu'aucune trace de connexion n'existe.
Encaissement: Prestataire hébergeant lui-même le formulaire de carte, plus un rail d'argent mobile quand les payeurs recensés n'emploient pas de carte bancaire.; Faire transiter un numéro de carte par votre serveur fait entrer tout le produit dans le champ des obligations de conformité des paiements par carte.
Envoi de courriel: Service transactionnel avec domaine authentifié, gabarits versionnés, et adresse de réponse par organisation quand le client écrit à ses propres utilisateurs.; Un message signé de votre domaine mais envoyé au nom d'un client fait porter à votre réputation les plaintes provoquées par ses listes.
Surveillance des erreurs: Collecte des erreurs étiquetée par organisation, sans donnée de client dans le message, et alerte séparée par locataire au-delà d'un seuil.; Une erreur qui ne touche qu'un seul locataire disparaît dans le total, alors que c'est précisément celle que ce client va signaler.
Intégration continue: Compilation, style, tests, test de bout en bout du parcours payant, et un test d'isolation qui vérifie qu'un compte du locataire A ne lit rien du locataire B.; Le test d'isolation est le seul qui vérifie la promesse commerciale du produit, et il doit échouer au moindre filtre oublié pour valoir quelque chose.
Budget de données et réseau: Premier écran rendu par le serveur, listes paginées, exports lourds produits en tâche de fond et retirés par lien plutôt que téléchargés en direct.; Un export produit en direct occupe la connexion pendant plusieurs minutes et échoue à chaque coupure, alors qu'un lien se retire quand le réseau revient.
Gestion des secrets: Gestionnaire de secrets dédié, clés distinctes par environnement, et aucune clé de client stockée en clair dans la base.; Une clé de client stockée en clair transforme une lecture de la base en compromission de tous les systèmes tiers de tous les clients.
Sauvegarde et restauration: Sauvegarde à un instant donné pour l'ensemble, et procédure écrite de restauration d'une seule organisation dans un environnement séparé.; Restaurer toute la base pour réparer l'erreur d'un seul client détruirait le travail de tous les autres depuis l'instant de la sauvegarde.
Journalisation et traçabilité: Piste d'audit en ajout seul par organisation, consultable par le client, portant l'auteur, la date, l'action et la valeur avant modification.; Un client d'entreprise demande qui a fait quoi et quand lors du premier désaccord interne, et un journal modifiable ne répond pas à la question.
Mesure de l'usage: Compteur d'usage par organisation reconstruit depuis un journal d'événements, et rapprochement quotidien avec ce qui est facturé.; Une facture d'usage contestée ne se défend qu'avec le journal d'événements qui l'a produite, et ce journal doit exister avant la contestation.

Ce qu’on écarte ici

Une base de données par client : elle multiplie les migrations par le nombre de clients et fait diverger les schémas dès la première migration échouée.
Un sous-domaine par client sur un certificat distinct : il ajoute une renouvellement à surveiller par client, pour un bénéfice uniquement cosmétique.
Une personnalisation du code par client : elle crée autant de produits que de clients et rend toute correction non généralisable.
Un tableau de bord d'administration transversal sans traçabilité : il donne à un employé la lecture de tous les clients sans qu'aucun client puisse le savoir.
Un encaissement par virement suivi à la main : il transforme chaque renouvellement en tâche humaine et fait perdre les abonnements les moins chers.

Logiciel en service, multi-organisations · Plateforme

Décision préalable : construire ou s'abstenir: On ne passe à l'ampleur plateforme que si un client a exigé par écrit une exigence que le produit ne peut pas satisfaire sans elle : résidence des données, isolation dédiée ou intégration par interface publique.; Chacune de ces trois exigences se lit dans un contrat signé, donc la décision se prend sur une pièce écrite et non sur une anticipation commerciale.
Langage et cadre applicatif: Programme unique modulaire, extraction d'un service seulement pour un module dont le rythme de livraison ou le profil de charge diffère de façon mesurée.; Un module extrait sans différence mesurée ajoute une panne de réseau possible entre deux fonctions qui ne peuvent plus être modifiées ensemble.
Base de données: Base partagée par défaut, réplicas de lecture pour les rapports des clients, migrations en deux temps, et aucune requête transversale sans filtre.; Faire porter les rapports par un réplica empêche l'export d'un gros client de ralentir les écritures de tous les autres au même instant.
Isolation des locataires: Base partagée par défaut, base dédiée pour un locataire seulement lorsqu'une exigence écrite l'impose, et le même code doit servir les deux cas.; Deux chemins de code selon le locataire doublent le coût de chaque correction et font diverger les deux versions sans que personne ne le remarque.
Authentification: Connexion déléguée à l'annuaire du client quand il en a un, approvisionnement automatique des comptes, et retrait automatique au départ d'un salarié.; Le retrait manuel d'un compte dépend d'un courriel que personne n'envoie, alors que le retrait automatique suit la décision déjà prise dans l'annuaire.
Hébergement: Plateforme gérée, déploiement progressif par vagues de locataires, et retour en arrière possible sans intervention sur la base.; Déployer par vagues expose d'abord les locataires les plus tolérants, ce qui transforme une régression en incident limité plutôt qu'en panne générale.
Stockage de fichiers: Stockage objet par organisation, cycle de vie déclaré, chiffrement au repos avec clé par client lorsque le contrat l'exige.; Une clé de chiffrement propre au client permet de rendre ses données illisibles en la détruisant, seule façon de prouver un effacement à une date donnée.
Encaissement: Abonnement et consommation facturés par un prestataire, encaissement par carte et par argent mobile, et bon de commande avec facturation différée pour les grands comptes.; Un grand compte ne paie pas par carte parce que son service achats exige un bon de commande, donc l'absence de ce mode de règlement bloque la vente.
Envoi de courriel: Envois transactionnels et envois de masse séparés sur deux domaines, délégation possible du domaine d'envoi au client, et journal de remise par message.; Le journal de remise est ce qui permet de répondre à un client qui affirme n'avoir rien reçu, sans quoi le désaccord ne se tranche jamais.
Surveillance des erreurs: Collecte reliée aux traces réparties, objectifs de service écrits par parcours, et alerte fondée sur la dégradation de ces objectifs.; Un objectif écrit avant l'incident permet de dire si l'incident est un manquement contractuel, décision qui autrement se prend au ressenti.
Intégration continue: Tests d'isolation entre locataires, tests de bout en bout des parcours payants, contrôle de migration en deux temps, et refus de fusion sur régression de performance mesurée.; Une régression de performance ne provoque aucune erreur et passe donc tous les autres contrôles, jusqu'à ce qu'un client la ressente.
Budget de données et réseau: Budget de données par écran contrôlé à chaque livraison, exports en tâche de fond, et interface allégée servie aux appareils les moins puissants.; Les utilisateurs finaux d'un client ne sont pas ses acheteurs, et ce sont eux qui abandonnent quand l'écran ne s'affiche pas sur leur appareil.
Quotas et limitation de débit: Quota par organisation adossé au contrat, dégradation lisible plutôt que coupure sèche, et alerte au client avant l'atteinte de la limite.; Une coupure sèche sans préavis se termine en réclamation commerciale, alors qu'une alerte avant la limite déplace la décision chez le client.
Ordonnancement des traitements: File de travaux par locataire ou pondérée, tâches idempotentes, et plafond de travail simultané par organisation.; Une file unique traitée dans l'ordre laisse l'import massif d'un seul locataire retarder les traitements de tous les autres pendant des heures.
Gestion des secrets: Gestionnaire de secrets dédié, identités de charge de travail entre services, et rotation automatique consignée.; Une rotation consignée est ce qui permet de répondre à un questionnaire de sécurité client par une preuve plutôt que par une intention.
Sauvegarde et restauration: Sauvegarde à un instant donné, copie hors région, restauration par organisation, et exercice trimestriel dont le résultat est écrit et daté.; Le délai de reprise annoncé dans un contrat n'est défendable que s'il a été chronométré lors d'un exercice réel et daté.
Journalisation et traçabilité: Piste d'audit en ajout seul, exportable par le client, avec durée de conservation écrite au contrat et purge automatique à échéance.; Conserver au-delà de la durée écrite crée une obligation de communication que le contrat n'avait pas prévue, et l'exposition qui va avec.
Mesure de l'usage: Journal d'événements d'usage par organisation, agrégats recalculables, et rapprochement quotidien entre l'usage mesuré et l'usage facturé.; Un écart entre usage mesuré et usage facturé se détecte le lendemain ou se découvre au trimestre, moment où il est devenu un litige.
Résidence des données: Région de stockage écrite au contrat de chaque client, changement de région traité comme une migration annoncée, et registre des sous-traitants tenu à jour.; Un client soumis à une règle de localisation de données résilie si la région change sans préavis, et le registre des sous-traitants est ce qu'il auditera.

Ce qu’on écarte ici

Une instance dédiée par client par confort commercial : elle multiplie les déploiements à surveiller sans qu'aucune exigence écrite ne l'impose.
Un moteur de règles configurable par le client : il déplace la complexité du code vers une configuration que personne ne teste et que le support ne sait pas lire.
Une place de marché d'extensions : elle exige une revue de sécurité par extension, métier à part entière que l'équipe n'exerce pas.
Un entrepôt de données temps réel : les rapports client se satisfont d'un réplica de lecture rafraîchi en quelques secondes, pour une fraction du coût.
Une multi-résidence par défaut : elle double l'exploitation pour tous les clients afin de servir l'exigence contractuelle de quelques-uns.

Automatisation interne · Prototype

Décision préalable : construire ou s'abstenir: On n'automatise que ce qui a été exécuté à la main au moins cinq fois et dont les étapes sont écrites et acceptées par ceux qui les exécutent.; L'automatisation fige la procédure, donc figer une procédure encore instable oblige à réécrire l'automatisation à chaque changement d'avis.
Langage et cadre applicatif: Un script dans le langage déjà pratiqué dans la maison, sans interface, dont le résultat est déposé dans le fichier ou la messagerie que l'équipe consulte déjà.; L'utilisateur de cette automatisation est un employé identifié, donc un rapport déposé là où il regarde déjà lui rend le service qu'une interface lui rendrait.
Base de données: Aucune base propre ; le script lit et écrit dans les systèmes existants et conserve son état dans une seule table ou un seul fichier d'exécutions.; Créer une base propre ferait de cette automatisation une troisième source de vérité à réconcilier avec les deux systèmes qu'elle relie.
Authentification: Compte de service dédié à l'automatisation, droits limités aux seules opérations nécessaires, jamais le compte personnel d'un employé.; Un compte personnel employé par un script cesse de fonctionner le jour du départ de la personne et rend chaque action du script inattribuable.
Hébergement: Ordonnanceur géré du fournisseur déjà employé par la maison, sans machine à administrer.; Une machine dédiée à un script demande des mises à jour de sécurité mensuelles qui coûteront plus cher que le temps que le script fait gagner.
Stockage de fichiers: Le dépôt de fichiers déjà employé par l'entreprise, avec un dossier par exécution nommé par sa date.; Un dossier par date permet de comparer deux exécutions pour comprendre un écart, ce qu'un fichier écrasé à chaque passage rend impossible.
Envoi de courriel: Aucun envoi vers l'extérieur ; le compte rendu est déposé dans le canal interne de l'équipe concernée.; Un script qui écrit à l'extérieur peut envoyer un message erroné à un client dès la première exécution ratée, risque sans contrepartie à ce stade.
Surveillance des erreurs: Échec bruyant : toute exécution en erreur envoie un message à une personne nommée, avec la trace complète et la date de la dernière exécution réussie.; Une automatisation qui échoue en silence est pire que son absence, parce que tout le monde croit la tâche faite et personne ne la refait.
Intégration continue: Contrôle de style et de compilation à chaque modification, et exécution obligatoire en mode simulation avant toute exécution réelle.; Un mode simulation qui affiche ce qui serait modifié sans le modifier est le seul moyen de valider une automatisation destructrice avant son premier passage.
Ordonnancement des traitements: Déclenchement planifié, verrou empêchant deux exécutions simultanées, et reprise idempotente à partir de la dernière exécution réussie.; Deux exécutions simultanées de la même tâche produisent des doublons que personne ne détecte avant la clôture comptable du mois.
Gestion des secrets: Coffre de secrets de l'entreprise ou variables de l'ordonnanceur, jamais dans le script ni dans un fichier de configuration versionné.; Un script d'automatisation détient par nature des droits d'écriture sur les systèmes de production, donc la clé qu'il porte vaut ces droits.

Ce qu’on écarte ici

Une interface web de pilotage : elle ajoute des écrans, une authentification et un hébergement pour une tâche que l'ordonnanceur déclenche seul.
Une plateforme d'automatisation sans code : elle rend la logique invisible au contrôle de version, donc impossible à relire et à revenir en arrière.
Un traitement en temps réel : une tâche exécutée à heure fixe suffit tant que personne n'a écrit combien de retard est inacceptable.
Une base de données propre : elle crée une troisième vérité à réconcilier avec les deux systèmes que le script relie déjà.
Une intelligence artificielle pour interpréter les cas ambigus : un cas ambigu doit remonter à un humain nommé, sinon l'erreur devient invisible.

Automatisation interne · Produit

Décision préalable : construire ou s'abstenir: On passe au produit quand une équipe qui n'a pas écrit le script en dépend pour son travail quotidien et doit pouvoir en consulter le résultat sans vous.; Cette dépendance transforme une commodité personnelle en service interne, donc elle impose une consultation autonome et une reprise après panne.
Langage et cadre applicatif: Le même langage, organisé en modules testables, avec une page de suivi en lecture seule listant les exécutions et leurs écarts.; Une page en lecture seule permet au métier de répondre lui-même à la question de savoir si le traitement a tourné, sans ouvrir de demande au support.
Base de données: Une table d'exécutions et une table d'écarts dans la base existante de l'entreprise, sans nouvelle instance à administrer.; Les écarts constatés doivent être relus et corrigés par le métier, donc ils doivent vivre là où le métier a déjà des droits de lecture.
Authentification: Compte de service pour l'exécution, et connexion des employés à la page de suivi par l'annuaire de l'entreprise, sans compte séparé.; Un compte séparé pour un outil interne survit au départ du salarié, alors que l'annuaire retire l'accès le jour même de la sortie.
Hébergement: Ordonnanceur géré et service de pages internes du fournisseur déjà employé, avec un environnement d'essai raccordé à des données de test.; Sans environnement d'essai raccordé à des données de test, toute vérification se fait sur les données réelles de l'entreprise.
Stockage de fichiers: Dépôt de fichiers de l'entreprise, un dossier par exécution, purge automatique après la durée de conservation écrite.; Des exports conservés indéfiniment finissent par contenir des données personnelles au-delà de la durée annoncée aux personnes concernées.
Envoi de courriel: Compte rendu quotidien envoyé à une liste nominative de responsables, avec le nombre d'éléments traités et le nombre d'écarts en objet du message.; Un chiffre dans l'objet du message se lit sans ouvrir le message, ce qui est la seule façon d'obtenir qu'un compte rendu quotidien soit réellement lu.
Surveillance des erreurs: Alerte immédiate à une personne nommée sur échec, plus une alerte sur absence d'exécution à l'heure prévue.; Une tâche qui ne démarre pas ne produit aucune erreur, donc seule une alerte sur son absence révèle une panne d'ordonnanceur.
Intégration continue: Tests automatisés des règles de calcul sur des jeux de données figés, exécution en simulation obligatoire, et refus de fusion sur écart de résultat non expliqué.; Un jeu de données figé transforme un changement de règle en différence visible ligne par ligne, ce qu'aucune relecture de code ne montre.
Ordonnancement des traitements: Ordonnancement avec verrou, réessai à délai croissant, et possibilité de rejouer une période donnée sans produire de double effet.; Rejouer une période est la seule réparation possible après une panne de plusieurs jours, et elle exige que chaque action porte une clé unique.
Gestion des secrets: Coffre de l'entreprise, un secret par système cible, et retrait immédiat du droit d'écriture sur les systèmes que le script ne modifie plus.; Un droit d'écriture conservé après le retrait d'une fonctionnalité reste exploitable par toute erreur future du script.
Journalisation et traçabilité: Journal d'exécutions consultable par le métier : date, volume traité, écarts, décision automatique prise et valeur avant modification.; Le métier doit pouvoir répondre à la question de savoir pourquoi une facture n'est pas partie sans demander un accès technique à quiconque.
Sauvegarde et restauration: Sauvegarde de la table d'exécutions avec le reste de la base de l'entreprise, et conservation des rapports jusqu'à la clôture de l'exercice.; Un contrôle comptable de fin d'exercice demande la trace des traitements automatiques de toute l'année, y compris de ceux qui ont échoué.

Ce qu’on écarte ici

Une interface d'administration complète : le métier a besoin de lire et de relancer, pas de modifier les règles depuis un écran.
Une file de messages entre étapes : elle se justifie quand les étapes changent de rythme, ce qui n'est pas le cas d'un traitement quotidien.
Un déclenchement par événement : il rend l'ordre des traitements non reproductible, alors qu'une clôture comptable exige de rejouer une journée à l'identique.
Une ouverture de l'outil à d'autres équipes sans requalification : des utilisateurs qui ne sont pas les auteurs font changer la nature du produit.
Un tableau de bord de mesures techniques pour le métier : le métier suit le nombre d'écarts, pas la durée d'exécution.

Service applicatif · Prototype

Décision préalable : construire ou s'abstenir: On ne publie une interface de programmation que si un consommateur nommé s'est engagé par écrit à l'appeler à une date convenue ; sinon on garde une fonction interne.; Une interface publiée devient un contrat que l'on ne peut plus casser, alors qu'une fonction interne se renomme sans prévenir personne.
Contrat d'interface: Description formelle écrite avant le code, versionnée dans le dépôt, servant de source unique aux exemples et à la documentation.; Un contrat écrit après le code décrit ce qui a été fait et non ce qui avait été promis, et le consommateur découvre l'écart en intégration.
Langage et cadre applicatif: Un langage typé, un seul service, réponses en JSON, et validation des entrées par un schéma déclaré au même endroit que le contrat.; Un schéma déclaré une fois et employé à la fois pour valider et pour documenter empêche la documentation de mentir sur ce qui est réellement accepté.
Base de données: Base relationnelle gérée avec migrations versionnées, et aucune structure interne visible dans les réponses.; Exposer les colonnes de la base fait de chaque renommage un changement cassant pour le consommateur, alors qu'une réponse traduite absorbe le renommage.
Authentification: Une clé par consommateur, transmise dans un en-tête, révocable individuellement, avec une clé distincte pour l'environnement d'essai.; Une clé unique partagée par tous les consommateurs ne peut pas être révoquée sans couper tout le monde le jour où l'un d'eux la divulgue.
Hébergement: Plateforme gérée, deux environnements, et adresses distinctes pour l'essai et la production annoncées dès la première documentation.; Un consommateur qui n'a pas d'adresse d'essai intègre directement contre la production et y crée des données de test que personne ne saura distinguer.
Stockage de fichiers: Aucun fichier dans le corps des requêtes ; les fichiers passent par une adresse signée obtenue en deux appels.; Un fichier transporté dans le corps d'un appel immobilise la mémoire du service pendant tout le téléversement et le fait tomber au-delà de quelques envois simultanés.
Envoi de courriel: Aucun envoi de courriel, sauf la notification de révocation d'une clé au contact technique enregistré du consommateur.; Une clé révoquée sans notification produit une panne chez le consommateur dont la cause lui est invisible et vous sera imputée.
Surveillance des erreurs: Collecte des erreurs avec identifiant de requête rendu au consommateur dans la réponse d'erreur, et alerte sur toute erreur inédite.; Un identifiant rendu au consommateur permet de retrouver l'appel exact dont il se plaint sans lui demander de le reproduire.
Intégration continue: Compilation, tests, et contrôle de non-régression du contrat qui fait échouer la fusion à toute suppression ou renommage d'un champ existant.; La suppression d'un champ est la seule modification qui casse un consommateur sans produire d'erreur chez vous, donc seul un contrôle automatique l'arrête.
Gestion des secrets: Clés des consommateurs stockées sous forme d'empreinte, jamais en clair, et affichées une seule fois à la création.; Une clé stockée en clair permet à quiconque lit la base d'appeler l'interface au nom de n'importe quel consommateur.

Ce qu’on écarte ici

Un langage de requête laissé au consommateur : il rend impossible de prévoir la charge d'une requête et de fixer un quota compréhensible.
Une passerelle d'interfaces : elle ajoute une couche de configuration à diagnostiquer pour un seul service et un seul consommateur.
La négociation de version par en-tête : elle rend le contrat invisible dans l'adresse appelée, donc indiscutable dans un ticket de support.
Les rappels sortants dès le prototype : ils exigent signature, réessai et journal de livraison, travail sans objet tant qu'un appel direct suffit.
Un portail développeur : la description formelle et une page d'exemples suffisent tant qu'il n'y a qu'un consommateur nommé.

Service applicatif · Produit

Décision préalable : construire ou s'abstenir: On passe au produit quand un deuxième consommateur intègre l'interface sans que vous ayez à lui expliquer quoi que ce soit par téléphone.; Cette intégration autonome prouve que le contrat écrit se suffit à lui-même, ce qui est la seule condition qui rende l'interface diffusable.
Contrat d'interface: Version dans le chemin appelé, ajouts autorisés à tout moment, retraits soumis à préavis écrit et à une période où les deux versions répondent.; Un consommateur ne met à jour son intégration que lorsqu'il a du temps, donc seule une période de double service évite de le couper au mauvais moment.
Langage et cadre applicatif: Un langage typé, service unique, pagination par curseur sur toute liste, et clé d'idempotence obligatoire sur toute écriture.; Une pagination par numéro de page saute ou répète des éléments quand la liste change entre deux appels, ce qu'un curseur empêche.
Base de données: Base relationnelle gérée, index posés d'après les requêtes mesurées, et réponses traduites depuis le modèle interne.; La traduction depuis le modèle interne est ce qui permet de refondre la base sans qu'aucun consommateur n'ait à modifier son intégration.
Authentification: Clé par consommateur avec portée restreinte aux seules opérations souscrites, rotation possible sans coupure grâce à deux clés actives.; Deux clés actives permettent au consommateur de basculer à son rythme, sans quoi la rotation devient une panne planifiée qu'il refusera.
Hébergement: Plateforme gérée, trois environnements, environnement d'essai peuplé de données factices stables et documentées.; Des données d'essai stables permettent au consommateur d'écrire ses propres tests automatisés, ce qui divise le nombre de tickets d'intégration.
Stockage de fichiers: Adresses signées de courte durée pour le dépôt et le retrait, contrôle du type réel du fichier, et plafond de taille documenté dans le contrat.; Un plafond non documenté produit un échec que le consommateur ne peut pas anticiper, donc il l'interprète comme une panne de votre service.
Envoi de courriel: Notifications techniques au contact enregistré de chaque consommateur : révocation de clé, préavis de retrait de version et incident majeur.; Un préavis envoyé à une adresse générique n'atteint pas la personne qui modifiera l'intégration, donc le contact technique doit être nominatif.
Surveillance des erreurs: Erreurs rendues avec un code stable, un message lisible et un identifiant de requête, et collecte côté service séparée par consommateur.; Un code d'erreur stable permet au consommateur de traiter le cas dans son code, alors qu'un message libre l'oblige à comparer des chaînes de caractères.
Intégration continue: Tests du contrat, tests de charge du parcours le plus appelé, et refus de fusion sur tout changement cassant non accompagné d'une nouvelle version.; Un changement cassant introduit sans nouvelle version se découvre chez le consommateur en production, seul endroit où il coûte cher.
Quotas et limitation de débit: Limite par clé et par fenêtre, en-têtes indiquant le reste et la date de réarmement, et code de refus documenté avec le délai d'attente conseillé.; Un consommateur qui ignore combien d'appels il lui reste ne peut pas ralentir avant d'être coupé, donc il sera coupé au moment le plus chargé.
Gestion des secrets: Empreintes des clés en base, gestionnaire de secrets pour les accès sortants, et journal des créations et révocations de clés.; Le journal des révocations est ce qui permet de dire quelle clé était active au moment d'un appel contesté.
Journalisation et traçabilité: Journal d'appels par consommateur portant la date, l'opération, le code de réponse et la durée, conservé pour la durée écrite au contrat.; Le journal d'appels est la seule pièce qui tranche un désaccord sur ce qui a été demandé et sur ce qui a été répondu.
Sauvegarde et restauration: Sauvegarde à un instant donné, et procédure écrite de reconstruction des clés de consommateurs sans avoir à les redistribuer.; Une restauration qui oblige à redistribuer toutes les clés transforme un incident de base en interruption chez tous les consommateurs à la fois.

Ce qu’on écarte ici

Un langage de requête laissé au consommateur : il rend le coût d'un appel imprévisible et le quota impossible à expliquer.
Une bibliothèque cliente maintenue par vous dans chaque langage : elle crée autant de produits à maintenir que de langages, avant que la demande existe.
Une authentification déléguée complète : la clé par consommateur suffit tant que l'interface n'agit pas au nom d'un utilisateur final.
Des rappels sortants sans journal de livraison : chaque incident se termine en désaccord sur qui n'a pas reçu quoi.
Une version majeure par trimestre : le coût du changement est porté par le consommateur, et il cessera d'intégrer avant de suivre le rythme.

Service applicatif · Plateforme

Décision préalable : construire ou s'abstenir: On ne passe à l'ampleur plateforme que lorsque l'interface est vendue pour elle-même, avec un prix écrit et des consommateurs qui ne sont pas vos clients d'origine.; Facturer l'interface impose de mesurer, de facturer et de défendre chaque appel, travail qui n'a aucune contrepartie tant que l'accès est offert.
Contrat d'interface: Description formelle publiée, politique de version écrite avec durée de vie minimale annoncée, et journal des modifications daté.; Une durée de vie minimale annoncée est ce qu'un acheteur regarde avant d'intégrer, parce qu'elle borne le coût de maintenance qu'il accepte.
Langage et cadre applicatif: Service modulaire dans un langage typé, pagination par curseur, idempotence obligatoire, et compatibilité ascendante vérifiée automatiquement.; La compatibilité ascendante ne se maintient pas par discipline sur plusieurs années, elle se maintient par un contrôle qui refuse la fusion.
Base de données: Base relationnelle principale, réplicas de lecture pour les appels de consultation massifs, et modèle de réponse indépendant du schéma interne.; Servir les lectures massives depuis un réplica empêche un consommateur qui parcourt tout son historique de ralentir les écritures de tous les autres.
Authentification: Clés à portée restreinte pour les accès serveur, délégation par jeton lorsque l'interface agit au nom d'un utilisateur final, et consentement conservé.; Agir au nom d'un utilisateur final sans consentement conservé rend impossible de prouver l'autorisation le jour où cet utilisateur conteste l'action.
Hébergement: Plateforme gérée multi-région pour les lectures, déploiement progressif, et page d'état publique alimentée par les mesures réelles.; Une page d'état alimentée à la main est publiée après l'incident, donc elle ne remplit pas la fonction pour laquelle le consommateur la consulte.
Stockage de fichiers: Adresses signées, cycle de vie déclaré, et quota de stockage par consommateur adossé à son contrat.; Sans quota de stockage, un seul consommateur peut faire porter à tous les autres le coût du stockage qu'il n'utilise plus.
Encaissement: Facturation à l'usage adossée au journal d'appels, seuil gratuit annoncé, et facturation différée sur bon de commande pour les grands comptes.; Un seuil gratuit annoncé permet au consommateur d'évaluer l'interface sans engagement d'achat, étape que son service achats impose avant tout contrat.
Envoi de courriel: Notifications techniques nominatives, avis de dépassement de quota avant coupure, et préavis de retrait de version au moins deux fois.; Un préavis unique arrive pendant les congés du seul intégrateur du consommateur, donc la répétition est ce qui rend le préavis effectif.
Surveillance des erreurs: Codes d'erreur stables et documentés, taux d'erreur suivi par consommateur, et objectifs de service écrits par opération.; Un taux d'erreur suivi par consommateur révèle une intégration fautive chez un seul appelant, cas que la moyenne globale dissimule entièrement.
Intégration continue: Tests de contrat, tests de charge, contrôle automatique de compatibilité ascendante, et publication de la documentation depuis la même source que le code.; Une documentation publiée séparément diverge du code dès la deuxième livraison, et le consommateur découvre l'écart en production.
Quotas et limitation de débit: Quota par contrat, limitation par opération et non seulement globale, dégradation annoncée avant coupure, et relèvement possible sans nouvelle intégration.; Une limitation seulement globale laisse un appel coûteux consommer le quota que le consommateur réservait à ses appels courants.
Ordonnancement des traitements: Rappels sortants signés, réessai à délai croissant, file d'échecs par consommateur et journal de livraison consultable par lui.; Sans journal de livraison consultable, chaque incident se termine en désaccord sur qui n'a pas reçu quoi et se règle au commercial.
Gestion des secrets: Empreintes de clés, gestionnaire de secrets, signature des rappels sortants par un secret partagé propre à chaque consommateur.; Un secret de signature partagé entre consommateurs permet à l'un d'eux de forger un rappel adressé à un autre.
Sauvegarde et restauration: Sauvegarde à un instant donné, copie hors région, exercice de restauration trimestriel, et conservation du journal d'appels pour la durée de facturation contestable.; Perdre le journal d'appels d'un mois rend indéfendable la facture de ce mois auprès de tous les consommateurs à la fois.
Journalisation et traçabilité: Journal d'appels immuable, exportable par le consommateur, et piste d'audit distincte pour les créations et révocations de clés.; Un consommateur qui peut exporter son propre journal cesse d'ouvrir des demandes pour obtenir des chiffres qu'il pourrait lire lui-même.
Mesure de l'usage: Compteur d'appels reconstruit depuis le journal, rapprochement quotidien avec la facturation, et tableau d'usage visible par le consommateur.; Un consommateur qui voit son usage en cours de mois corrige lui-même son intégration avant de recevoir une facture qu'il contesterait.

Ce qu’on écarte ici

Une passerelle propriétaire pour la limitation : la limitation doit connaître le contrat du consommateur, information que seule l'application détient.
Une facturation à la ressource plutôt qu'à l'appel : elle produit une facture que le consommateur ne peut pas rapprocher de son propre journal.
Un bac à sable partagé entre consommateurs : les données d'essai de l'un troublent les tests automatisés de l'autre.
Une place de marché d'extensions : elle impose une revue de sécurité par extension, discipline distincte de la vôtre.
La suppression d'une version au premier préavis : le consommateur qui n'a pas migré devient un incident public, pas un client discipliné.