Thèmes transversaux

La même question revient dans des domaines différents. Ces étiquettes traversent les huit domaines.

Planification et décisionMesureUtilisateursArchitectureDonnéesPerformancesFiabilitéSécuritéConfidentialitéCoûtTestsDéploiementSupervisionDocumentationProcessus et équipesPrestataires et tiersCompatibilité et changementMaintenance dans la duréeExpériencesInterfaces

Planification et décision

Définir un problème, prioriser et choisir ce qu'on ne fait pas

16 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · Sécurité · L'IA en pratique · Métier, qualité et équipes
001D'une idée à un problème que l'on peut résoudreAvant de choisir une technologie, écrivez qui subit le problème, ce que cette personne fait aujourd'hui à la place, et comment vous saurez qu'il est résolu.002Le plus petit prototype qui prouve quelque choseUn prototype sert à répondre à une question dangereuse, pas à faire une démonstration : il a donc le droit d'être laid, manuel et incomplet.003Rédiger une spécification que les développeurs liront vraimentUne bonne spécification décrit des comportements et des critères d'acceptation, pas des maquettes — et sa longueur se compte en pages, pas en dizaines.004Choisir ce qu'on ne construira pasLa capacité à dire non est ce qui sépare un produit livré d'un produit développé à l'infini.005Combien de temps cela prendra : des estimations sans illusionsUne bonne estimation est une plage avec des hypothèses visibles, mise à jour à mesure que la connaissance grandit — pas un unique chiffre dit une fois.006Construire, acheter ou intégrerConstruisez uniquement ce qui vous distingue ; tout le reste, achetez-le, intégrez-le ou abandonnez-le.007Recherche utilisateur en trois joursCinq conversations d'une demi-heure avec des personnes qui font le travail révèlent plus qu'un sondage de mille réponses.009Dette technique : quand la contracter et quand la rembourserLa dette technique est un outil de financement légitime, à condition d'être contractée délibérément, enregistrée, et d'avoir une date à laquelle on en parle.010Première version : ce qui doit entrerLa première version doit faire une chose de bout en bout, et la faire d'une façon sur laquelle on peut compter.011Comment prioriser quand tout le monde crieLa priorisation n'est pas une liste ordonnée mais une règle de décision que tout le monde connaît à l'avance ; sinon, c'est celui qui parle le plus fort qui la fixe.012De la spécification à des tâches sur lesquelles on peut commencer à travaillerUne bonne tâche se termine par un résultat qu'on peut exécuter et vérifier, et dure un à deux jours — pas une semaine, pas une heure.021Native, multiplateforme ou site web mobileLe choix est déterminé par ce dont vous avez besoin de l'appareil et par la taille de l'équipe — pas par la technologie à la mode cette année.061Un modèle de menaces en une heureEsquissez ce que vous avez, qui pourrait le vouloir et où cela franchit une frontière — et vous obtenez une vraie liste de priorités au lieu d'un ressenti.075Comment choisir un modèle — et pourquoi ce n'est pas la première décisionCommencez avec le modèle le plus puissant pour tester si la tâche est résoluble, et seulement ensuite descendez vers un moins cher jusqu'à ce que la qualité se brise.097Choisir une technologie sans le regretter dans deux ansChoisissez selon l'équipe, la maturité et la communauté — et ce qui est ennuyeux et familier l'emporte presque toujours sur ce qui est nouveau et excitant.100Ce qui décide vraiment si un projet réussitPas la technologie ni la taille de l'équipe — mais la clarté de l'objectif, les courts cycles de retour et une personne responsable de décider.

Mesure

Savoir si quelque chose s'est vraiment amélioré

12 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · Infrastructure, cloud et DevOps · L'IA en pratique · Métier, qualité et équipes
001D'une idée à un problème que l'on peut résoudreAvant de choisir une technologie, écrivez qui subit le problème, ce que cette personne fait aujourd'hui à la place, et comment vous saurez qu'il est résolu.002Le plus petit prototype qui prouve quelque choseUn prototype sert à répondre à une question dangereuse, pas à faire une démonstration : il a donc le droit d'être laid, manuel et incomplet.008Des métriques de succès qui ne mentent pasChoisissez une métrique liée à la valeur reçue par l'utilisateur, et une à côté qui vous empêche de casser autre chose.025Performances mobiles : mémoire, batterie et impression de vitesseDans les applications, l'impression se joue au démarrage et dans la fluidité du défilement — et les deux sont brisés par les images et le travail qui s'exécute sur le thread principal.029Surveillance des plantages et erreurs dans une applicationSans rapport automatique de plantage, vous apprenez les problèmes par les avis de la boutique — c'est-à-dire trop tard.052Surveillance et observabilité : savoir que quelque chose s'est cassé avant le clientTrois types de signaux — métriques, journaux et traces — et une question à laquelle ils doivent répondre : que se passe-t-il maintenant et pourquoi.054Coûts cloud : où va l'argentLa plupart de la facture vient de trois endroits : des ressources qui tournent sans que personne n'en ait besoin, du stockage qui croît sans politique, et du trafic entre régions.079Évaluation : comment savoir que le système s'est amélioréSans ensemble d'évaluation fixe, chaque changement est une croyance — et une amélioration dans un domaine cachera une régression dans un autre.081Classification et extraction : les tâches qui rapportent le plusAvant de construire un chat, vérifiez si le problème est en réalité de classifier une demande ou d'extraire des champs d'un document — deux tâches simples qui rapportent de la valeur immédiate.082Hallucinations : pourquoi ça arrive et ce qui aide vraimentUn modèle interrogé sur une question sans réponse produira une réponse plausible — la solution n'est pas de lui demander de ne pas se tromper mais de lui donner une source et un moyen de dire non.088Expériences : comment savoir que le changement a amélioré quelque choseComparez deux versions sur le même trafic au même moment — toute comparaison « avant et après » mesure aussi le monde, pas seulement vous.100Ce qui décide vraiment si un projet réussitPas la technologie ni la taille de l'équipe — mais la clarté de l'objectif, les courts cycles de retour et une personne responsable de décider.

Utilisateurs

Ce qui se passe du côté de la personne qui utilise le système

11 articles
Apparaît aussi dans : Fondations produit · Web et frontend · Applications mobiles · Sécurité · L'IA en pratique
007Recherche utilisateur en trois joursCinq conversations d'une demi-heure avec des personnes qui font le travail révèlent plus qu'un sondage de mille réponses.014Performances dans le navigateur : ce qui ralentit vraiment un siteDans la plupart des sites lents, le coupable n'est pas le code mais le poids — grandes images, polices et scripts tiers.015Accessibilité : le minimum qu'on ne peut pas esquiverLa majeure partie de l'accessibilité vient d'un HTML correctement écrit, et la plupart des échecs viennent du remplacement d'éléments standard par quelque chose de dessiné pour y ressembler.016Design adaptatif sans douleurCommencez par le petit écran, laissez le contenu décider où il se brise, et ne designez pas pour une liste d'appareils.017SEO technique pour les sites modernesAvant les mots-clés, assurez-vous que le moteur de recherche peut atteindre la page, la lire et comprendre ce qu'elle est.019Formulaires : la partie où on perd le plus d'utilisateursUn bon formulaire demande peu, vérifie au bon moment, explique une erreur là où elle s'est produite, et n'efface pas ce qui a été tapé.020Hébreu et de droite à gauche : ce qui se casse et comment réparerLa plupart des bugs droite-à-gauche viennent de l'utilisation de gauche et droite au lieu de début et fin — et du texte mixte qui se heurte sur une ligne.023Notifications push sans perdre d'utilisateursUne notification justifiée est une dont l'absence serait regrettée par l'utilisateur — tout le reste mène à désactiver l'autorisation, ce qui est presque irréversible.028Expérience utilisateur sur mobile : ce qui diffère d'un grand écranSur mobile, l'utilisateur est debout, pressé, tient avec une main et parfois en plein soleil — et cela change chaque décision.063Mots de passe, double facteur et sessionsStockez les mots de passe avec un algorithme lent dédié, activez le double facteur, et rendez possible la déconnexion de tous les appareils.084Concevoir une interface pour un système qui n'a pas toujours raisonUne bonne interface montre une certitude variable, permet une correction facile, et ne présente pas une supposition comme un fait.

Architecture

Comment les composants sont découpés et communiquent

16 articles
Apparaît aussi dans : Web et frontend · Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · L'IA en pratique · Métier, qualité et équipes
013Choisir entre un site statique, un site rendu côté serveur et une application navigateurPlus le contenu est fixe, plus l'architecture doit être simple — et chaque couche de dynamisme ajoutée se paye chaque jour.018Gestion de l'état dans une application webLa plupart de ce qu'on appelle état est de la donnée serveur stockée au mauvais endroit — séparez-les et la moitié de la complexité disparaît.021Native, multiplateforme ou site web mobileLe choix est déterminé par ce dont vous avez besoin de l'appareil et par la taille de l'équipe — pas par la technologie à la mode cette année.022Travailler hors ligne : une application qui ne se casse pas dans un ascenseurConcevez l'application autour de l'hypothèse qu'il n'y a pas de réseau, et vous obtenez gratuitement une application qui se sent aussi rapide quand il y en a un.034Bases de données : choisir et ne pas regretterDans la plupart des cas, une base de données relationnelle est la bonne réponse, et tout autre choix nécessite une raison qu'on peut énoncer en une phrase.036Files d'attente et travaux d'arrière-planTout ce qui prend plus d'une seconde et n'est pas nécessaire à la réponse à l'utilisateur appartient à une file, pas à la requête.037Cache : accélérer sans servir des données périméesAvant d'ajouter un cache, décidez combien de temps une donnée périmée est encore acceptable — c'est la seule question qui compte vraiment.039Un service ou plusieurs : quand diviserCommencez avec un système bien ordonné. Divisez seulement quand il y a une vraie douleur — des équipes qui se bloquent mutuellement ou un composant qui nécessite une échelle différente.040Concevoir un modèle de données qui tient des annéesUn bon modèle représente la réalité commerciale, pas le premier écran qu'on vous a demandé de construire.042Fichiers et stockage d'objetsLes fichiers n'appartiennent ni à la base de données ni au disque du serveur — ils appartiennent au stockage d'objets avec des adresses signées.055Mise à l'échelle : horizontale, verticale et ce dont on a vraiment besoinAvant de mettre à l'échelle, mesurez où se trouve le goulot d'étranglement — dans la plupart des systèmes, c'est la base de données ou une requête, pas le nombre de serveurs.076Connecter votre connaissance au modèle : la récupération sans grands motsLe modèle ne connaît pas vos documents — vous devez trouver les passages pertinents pour chaque question et les joindre au prompt.077Agents : quand laisser le système agir seulUn agent décide lui-même quelles actions effectuer — et tout le bénéfice et le risque résident dans les permissions que vous lui avez accordées.087Automatisation des processus : où un modèle ajoute et où il est superfluSi le processus est fixe et clair, écrivez du code ; un modèle vaut exactement là où un jugement sur du texte non structuré est nécessaire.089Architecture d'un système basé sur un modèleLe modèle est un composant à l'intérieur d'un système ordinaire — et le système autour de lui est la majeure partie du travail et du risque.096Noms, structure et code vers lequel on peut revenirLe code est lu bien plus qu'il n'est écrit — donc un nom précis et une structure prévisible valent plus que n'importe quelle ingéniosité.

Données

Structure, stockage et intégrité de l'information

13 articles
Apparaît aussi dans : Web et frontend · Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · Sécurité · L'IA en pratique
018Gestion de l'état dans une application webLa plupart de ce qu'on appelle état est de la donnée serveur stockée au mauvais endroit — séparez-les et la moitié de la complexité disparaît.022Travailler hors ligne : une application qui ne se casse pas dans un ascenseurConcevez l'application autour de l'hypothèse qu'il n'y a pas de réseau, et vous obtenez gratuitement une application qui se sent aussi rapide quand il y en a un.026Stockage local et données sensibles sur l'appareilSupposez que l'appareil sera perdu ou compromis : ce qui est stocké localement doit être minimal, chiffré et révocable à distance.034Bases de données : choisir et ne pas regretterDans la plupart des cas, une base de données relationnelle est la bonne réponse, et tout autre choix nécessite une raison qu'on peut énoncer en une phrase.035Migrations de schéma sans temps d'arrêtModifiez le schéma en étapes compatibles ascendantes : ajoutez, remplissez, changez et seulement à la fin — supprimez.040Concevoir un modèle de données qui tient des annéesUn bon modèle représente la réalité commerciale, pas le premier écran qu'on vous a demandé de construire.043Recherche : quand la base de données ne suffit plusLa recherche plein texte avec classement, fautes de frappe et filtre multiple est un monde à part — et tous les systèmes n'en ont pas besoin.046Travailler avec l'argent : paiements et débitsNe stockez jamais les données de carte, ne faites jamais confiance à un montant venu du client, et tenez toujours un journal d'événements immuable.053Sauvegarde et restauration : ce qui n'est pas testé n'existe pasUne sauvegarde n'est pas une politique ; une politique, c'est combien de données vous pouvez perdre et combien de temps vous pouvez être en panne — et la preuve que vous l'avez respecté.069Confidentialité dès la conception : collecter moinsLa façon la moins chère de protéger les informations est de ne pas les collecter — et chaque champ collecté doit avoir un objectif, un propriétaire et une date de suppression.076Connecter votre connaissance au modèle : la récupération sans grands motsLe modèle ne connaît pas vos documents — vous devez trouver les passages pertinents pour chaque question et les joindre au prompt.081Classification et extraction : les tâches qui rapportent le plusAvant de construire un chat, vérifiez si le problème est en réalité de classifier une demande ou d'extraire des champs d'un document — deux tâches simples qui rapportent de la valeur immédiate.083Données : d'où elles viennent et quoi faire quand il n'y en a pasDans la plupart des projets, les données existent mais sont éparpillées, non étiquetées et non nettoyées — et c'est l'étape qui mange la plupart du temps.

Performances

Vitesse, charge et ressenti pour l'utilisateur

11 articles
Apparaît aussi dans : Web et frontend · Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · L'IA en pratique
013Choisir entre un site statique, un site rendu côté serveur et une application navigateurPlus le contenu est fixe, plus l'architecture doit être simple — et chaque couche de dynamisme ajoutée se paye chaque jour.014Performances dans le navigateur : ce qui ralentit vraiment un siteDans la plupart des sites lents, le coupable n'est pas le code mais le poids — grandes images, polices et scripts tiers.017SEO technique pour les sites modernesAvant les mots-clés, assurez-vous que le moteur de recherche peut atteindre la page, la lire et comprendre ce qu'elle est.025Performances mobiles : mémoire, batterie et impression de vitesseDans les applications, l'impression se joue au démarrage et dans la fluidité du défilement — et les deux sont brisés par les images et le travail qui s'exécute sur le thread principal.031Fichiers, médias et téléversements depuis l'appareilUne photo de l'appareil photo pèse des dizaines de fois plus que nécessaire — traitez-la sur l'appareil avant qu'elle ne touche le réseau.037Cache : accélérer sans servir des données périméesAvant d'ajouter un cache, décidez combien de temps une donnée périmée est encore acceptable — c'est la seule question qui compte vraiment.043Recherche : quand la base de données ne suffit plusLa recherche plein texte avec classement, fautes de frappe et filtre multiple est un monde à part — et tous les systèmes n'en ont pas besoin.045Charge : limites de débit et auto-protectionUn système sain refuse tôt et clairement, plutôt que de s'effondrer lentement sous une charge qu'il ne peut pas supporter.055Mise à l'échelle : horizontale, verticale et ce dont on a vraiment besoinAvant de mettre à l'échelle, mesurez où se trouve le goulot d'étranglement — dans la plupart des systèmes, c'est la base de données ou une requête, pas le nombre de serveurs.080Coûts et latence dans les systèmes basés sur des modèlesLa plupart du coût vient du texte entrant, et la plupart de la latence du texte sortant — c'est pourquoi les deux corrections diffèrent.086Modèles petits, locaux et en périphérieQuand le volume est grand, la latence critique ou les données ne peuvent pas sortir — un petit modèle de votre côté bat un grand modèle dans le cloud.

Fiabilité

Ce qui se passe quand quelque chose casse

13 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · L'IA en pratique
010Première version : ce qui doit entrerLa première version doit faire une chose de bout en bout, et la faire d'une façon sur laquelle on peut compter.022Travailler hors ligne : une application qui ne se casse pas dans un ascenseurConcevez l'application autour de l'hypothèse qu'il n'y a pas de réseau, et vous obtenez gratuitement une application qui se sent aussi rapide quand il y en a un.036Files d'attente et travaux d'arrière-planTout ce qui prend plus d'une seconde et n'est pas nécessaire à la réponse à l'utilisateur appartient à une file, pas à la requête.041Fiabilité dans les appels aux services externesChaque appel sortant échouera à un moment donné — la seule question est de savoir si vous avez planifié ce qui se passe alors.044E-mails sortants, messages et webhooksLes messages sortants sont une interface publique : ils ont besoin d'une file, de réessais et d'un enregistrement de ce qui a été envoyé à qui.045Charge : limites de débit et auto-protectionUn système sain refuse tôt et clairement, plutôt que de s'effondrer lentement sous une charge qu'il ne peut pas supporter.051Stratégies de déploiement : bleu-vert, canari et progressifUn bon déploiement se mesure par la capacité à revenir en arrière rapidement, pas par la vitesse de sortie.053Sauvegarde et restauration : ce qui n'est pas testé n'existe pasUne sauvegarde n'est pas une politique ; une politique, c'est combien de données vous pouvez perdre et combien de temps vous pouvez être en panne — et la preuve que vous l'avez respecté.056Réseaux et certificats : domaine, DNS et HTTPSLa plupart des incidents « le site ne se charge pas » sont un domaine, un certificat expiré ou le routage — pas le code.058Revue d'incident sans recherche de coupablesAprès chaque incident, une heure de revue écrite centrée sur le système et non la personne en vaut la peine — sinon le même incident reviendra.059Haute disponibilité et reprise après sinistreDécidez combien vous coûte une heure d'arrêt et seulement ensuite décidez combien de redondance acheter.082Hallucinations : pourquoi ça arrive et ce qui aide vraimentUn modèle interrogé sur une question sans réponse produira une réponse plausible — la solution n'est pas de lui demander de ne pas se tromper mais de lui donner une source et un moyen de dire non.089Architecture d'un système basé sur un modèleLe modèle est un composant à l'intérieur d'un système ordinaire — et le système autour de lui est la majeure partie du travail et du risque.

Sécurité

Penser comme un attaquant avant qu'il ne le fasse

19 articles
Apparaît aussi dans : Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · Sécurité · L'IA en pratique
026Stockage local et données sensibles sur l'appareilSupposez que l'appareil sera perdu ou compromis : ce qui est stocké localement doit être minimal, chiffré et révocable à distance.038Authentification et autorisation : qui vous êtes et ce qui vous est permisL'identité et l'autorisation sont deux questions distinctes, et la plupart des failles viennent de ce que la seconde est vérifiée dans l'interface et non dans le serveur.046Travailler avec l'argent : paiements et débitsNe stockez jamais les données de carte, ne faites jamais confiance à un montant venu du client, et tenez toujours un journal d'événements immuable.056Réseaux et certificats : domaine, DNS et HTTPSLa plupart des incidents « le site ne se charge pas » sont un domaine, un certificat expiré ou le routage — pas le code.057Gérer les secrets et les clésUn secret dans le dépôt de code est un secret qui a fuité — même si le dépôt est privé, et même si vous l'avez supprimé après.061Un modèle de menaces en une heureEsquissez ce que vous avez, qui pourrait le vouloir et où cela franchit une frontière — et vous obtenez une vraie liste de priorités au lieu d'un ressenti.062Les dix défauts qui reviennent dans chaque auditLa plupart des constats ne sont pas sophistiqués : des permissions non vérifiées côté serveur, des entrées qui arrivent dans une requête, et de vieilles bibliothèques.063Mots de passe, double facteur et sessionsStockez les mots de passe avec un algorithme lent dédié, activez le double facteur, et rendez possible la déconnexion de tous les appareils.064Injections : séparer une instruction des donnéesChaque endroit où une chaîne de l'utilisateur est assemblée dans une commande est une faille — et la solution, ce sont les paramètres, pas le filtrage.065Sécuriser les interfaces publiquesUne interface ouverte à internet est scannée automatiquement dès le premier jour — supposez que chaque route sera appelée, dans n'importe quel ordre, avec n'importe quelle entrée.066La chaîne d'approvisionnement du codeVotre code est une minorité de ce qui tourne en production — la plupart du risque réside dans les paquets que vous avez apportés et les outils qui les ont construits.067Chiffrement : quand, où et comment ne pas se tromperUtilisez des bibliothèques connues avec des valeurs par défaut modernes, et n'inventez rien — presque chaque échec de chiffrement est un échec d'utilisation.068Permissions cloud : la règle la plus importante est le minimumLa plupart des incidents cloud graves commencent avec une identité qui a plus de permissions que nécessaire et sans expiration.070Sécurité dans le navigateur : des protections activées dans les en-têtesUne grande partie des attaques côté client est bloquée par quelques en-têtes de réponse et quelques bons paramètres de cookie.071Sécurité de l'équipe : là où la plupart des failles commencentMême un système sécurisé est pénétré via l'appareil d'un employé, un e-mail de phishing ou un compte sans double facteur.072Tests de sécurité : quoi commander et quandLe scan automatique est une hygiène continue ; un test de pénétration est un événement ciblé — et les deux ont besoin d'un objectif écrit.073Sécurité dans les systèmes basés sur des modèlesUn modèle ajoute deux nouveaux risques : du contenu externe interprété comme une instruction, et une sortie qui atteint un endroit sensible sans vérification.074Se préparer à un incident avant qu'il arrivePendant un incident, il n'y a pas le temps de décider qui décide — le papier écrit par un matin calme fait la différence entre une heure et une semaine.077Agents : quand laisser le système agir seulUn agent décide lui-même quelles actions effectuer — et tout le bénéfice et le risque résident dans les permissions que vous lui avez accordées.

Confidentialité

Collecter moins et protéger ce qui est collecté

5 articles
Apparaît aussi dans : Applications mobiles · Infrastructure, cloud et DevOps · Sécurité · L'IA en pratique
026Stockage local et données sensibles sur l'appareilSupposez que l'appareil sera perdu ou compromis : ce qui est stocké localement doit être minimal, chiffré et révocable à distance.060Journaux : stocker correctement et trouver rapidementUn bon journal est structuré, identifié par un ID de requête, conservé pendant une durée définie, et libre d'informations personnelles n'ayant aucune raison d'y être.067Chiffrement : quand, où et comment ne pas se tromperUtilisez des bibliothèques connues avec des valeurs par défaut modernes, et n'inventez rien — presque chaque échec de chiffrement est un échec d'utilisation.069Confidentialité dès la conception : collecter moinsLa façon la moins chère de protéger les informations est de ne pas les collecter — et chaque champ collecté doit avoir un objectif, un propriétaire et une date de suppression.085Biais, équité et responsabilité dans l'utilisation des modèlesUn modèle reflète ce qu'il a vu — donc les décisions qui touchent les personnes nécessitent une vérification par segments, un humain dans la boucle et de la documentation.

Coût

Combien ça coûte, et pourquoi ça augmente

7 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · L'IA en pratique
006Construire, acheter ou intégrerConstruisez uniquement ce qui vous distingue ; tout le reste, achetez-le, intégrez-le ou abandonnez-le.031Fichiers, médias et téléversements depuis l'appareilUne photo de l'appareil photo pèse des dizaines de fois plus que nécessaire — traitez-la sur l'appareil avant qu'elle ne touche le réseau.042Fichiers et stockage d'objetsLes fichiers n'appartiennent ni à la base de données ni au disque du serveur — ils appartiennent au stockage d'objets avec des adresses signées.054Coûts cloud : où va l'argentLa plupart de la facture vient de trois endroits : des ressources qui tournent sans que personne n'en ait besoin, du stockage qui croît sans politique, et du trafic entre régions.075Comment choisir un modèle — et pourquoi ce n'est pas la première décisionCommencez avec le modèle le plus puissant pour tester si la tâche est résoluble, et seulement ensuite descendez vers un moins cher jusqu'à ce que la qualité se brise.080Coûts et latence dans les systèmes basés sur des modèlesLa plupart du coût vient du texte entrant, et la plupart de la latence du texte sortant — c'est pourquoi les deux corrections diffèrent.086Modèles petits, locaux et en périphérieQuand le volume est grand, la latence critique ou les données ne peuvent pas sortir — un petit modèle de votre côté bat un grand modèle dans le cloud.

Tests

Attraper les défaillances avant la production

6 articles
Apparaît aussi dans : Infrastructure, cloud et DevOps · Sécurité · L'IA en pratique · Métier, qualité et équipes
050Un pipeline automatisé de build et déploiementChaque fusion devrait déclencher la même séquence : build, tests, vérifications de sécurité, déploiement — sans une seule étape manuelle au milieu.062Les dix défauts qui reviennent dans chaque auditLa plupart des constats ne sont pas sophistiqués : des permissions non vérifiées côté serveur, des entrées qui arrivent dans une requête, et de vieilles bibliothèques.072Tests de sécurité : quoi commander et quandLe scan automatique est une hygiène continue ; un test de pénétration est un événement ciblé — et les deux ont besoin d'un objectif écrit.079Évaluation : comment savoir que le système s'est amélioréSans ensemble d'évaluation fixe, chaque changement est une croyance — et une amélioration dans un domaine cachera une régression dans un autre.091Tests : combien, lesquels et lesquels ne valent pas la peineInvestissez dans une majorité de tests qui exercent votre logique, quelques tests d'intégration et très peu de tests bout à bout.098Qualité sans bureaucratie : comment ne pas casser ce qui fonctionneLes régressions sont évitées par trois choses : des tests automatiques, des publications petites et fréquentes, et la capacité de revenir en arrière rapidement.

Déploiement

Comment le code passe en production et comment revenir en arrière

8 articles
Apparaît aussi dans : Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · Métier, qualité et équipes
030Déploiement progressif et interrupteurs de capacitéPubliez à un petit pourcentage, observez les métriques et élargissez — et conservez la capacité de désactiver une fonctionnalité sans publier une version.035Migrations de schéma sans temps d'arrêtModifiez le schéma en étapes compatibles ascendantes : ajoutez, remplissez, changez et seulement à la fin — supprimez.047Environnements : développement, test et productionTrois environnements construits depuis la même définition, ne différant que par la configuration et les données — toute autre différence est un bug qui attend d'être trouvé.048Conteneurs : ce qu'ils apportent et quand ils sont superflusUn conteneur emballe l'application avec tout ce dont elle a besoin pour tourner, de sorte qu'elle se comporte pareil partout.049Infrastructure comme codeSi vous ne pouvez pas reproduire l'environnement depuis un fichier en contrôle de version, vous n'avez pas d'infrastructure mais un historique de clics.050Un pipeline automatisé de build et déploiementChaque fusion devrait déclencher la même séquence : build, tests, vérifications de sécurité, déploiement — sans une seule étape manuelle au milieu.051Stratégies de déploiement : bleu-vert, canari et progressifUn bon déploiement se mesure par la capacité à revenir en arrière rapidement, pas par la vitesse de sortie.098Qualité sans bureaucratie : comment ne pas casser ce qui fonctionneLes régressions sont évitées par trois choses : des tests automatiques, des publications petites et fréquentes, et la capacité de revenir en arrière rapidement.

Supervision

Savoir ce qui se passe maintenant, et pourquoi

4 articles
Apparaît aussi dans : Applications mobiles · Infrastructure, cloud et DevOps · L'IA en pratique
029Surveillance des plantages et erreurs dans une applicationSans rapport automatique de plantage, vous apprenez les problèmes par les avis de la boutique — c'est-à-dire trop tard.052Surveillance et observabilité : savoir que quelque chose s'est cassé avant le clientTrois types de signaux — métriques, journaux et traces — et une question à laquelle ils doivent répondre : que se passe-t-il maintenant et pourquoi.060Journaux : stocker correctement et trouver rapidementUn bon journal est structuré, identifié par un ID de requête, conservé pendant une durée définie, et libre d'informations personnelles n'ayant aucune raison d'y être.090Opérer un système IA dans le tempsLes modèles se remplacent, les documents changent et les utilisateurs apprennent à poser des questions différemment — un système non touché pendant six mois est presque toujours moins bon.

Documentation

Ce qu'on ne peut pas déduire du code

6 articles
Apparaît aussi dans : Fondations produit · Backend, API et données · L'IA en pratique · Métier, qualité et équipes
003Rédiger une spécification que les développeurs liront vraimentUne bonne spécification décrit des comportements et des critères d'acceptation, pas des maquettes — et sa longueur se compte en pages, pas en dizaines.032Concevoir une interface avec laquelle on peut vivreUne bonne interface est prévisible, cohérente et ennuyeuse — chaque surprise en elle devient une question récurrente et un bug pour celui qui l'utilise.078Prompts : écrire une spécification, pas un sortilègeUn bon prompt définit un rôle, l'entrée, les règles de décision et la structure de sortie — et est traité comme du code, en contrôle de version et avec des tests.092Revue de code qui améliore plutôt que retardeUne bonne revue est petite, rapide et centrée sur la correction et la maintenabilité — pas sur les préférences de style qu'un outil automatique devrait appliquer.094De la documentation que les gens lisent vraimentDocumentez ce qu'on ne peut pas déduire du code : des décisions, des limites et la façon de commencer — tout le reste vieillit et induit en erreur.095Intégrer un nouveau développeur en une semaine, pas un moisLa métrique, c'est combien de temps passe jusqu'au premier changement en production — et la plupart du délai, ce sont les accès et la configuration locale, pas la compréhension du code.

Processus et équipes

Comment travailler ensemble sans se bloquer

22 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · Sécurité · L'IA en pratique · Métier, qualité et équipes
005Combien de temps cela prendra : des estimations sans illusionsUne bonne estimation est une plage avec des hypothèses visibles, mise à jour à mesure que la connaissance grandit — pas un unique chiffre dit une fois.011Comment prioriser quand tout le monde crieLa priorisation n'est pas une liste ordonnée mais une règle de décision que tout le monde connaît à l'avance ; sinon, c'est celui qui parle le plus fort qui la fixe.012De la spécification à des tâches sur lesquelles on peut commencer à travaillerUne bonne tâche se termine par un résultat qu'on peut exécuter et vérifier, et dure un à deux jours — pas une semaine, pas une heure.024Passer l'examen de la boutique du premier coupLa plupart des rejets viennent des métadonnées et des autorisations, pas du code — et peuvent être évités avec une heure de préparation.039Un service ou plusieurs : quand diviserCommencez avec un système bien ordonné. Divisez seulement quand il y a une vraie douleur — des équipes qui se bloquent mutuellement ou un composant qui nécessite une échelle différente.047Environnements : développement, test et productionTrois environnements construits depuis la même définition, ne différant que par la configuration et les données — toute autre différence est un bug qui attend d'être trouvé.049Infrastructure comme codeSi vous ne pouvez pas reproduire l'environnement depuis un fichier en contrôle de version, vous n'avez pas d'infrastructure mais un historique de clics.050Un pipeline automatisé de build et déploiementChaque fusion devrait déclencher la même séquence : build, tests, vérifications de sécurité, déploiement — sans une seule étape manuelle au milieu.057Gérer les secrets et les clésUn secret dans le dépôt de code est un secret qui a fuité — même si le dépôt est privé, et même si vous l'avez supprimé après.058Revue d'incident sans recherche de coupablesAprès chaque incident, une heure de revue écrite centrée sur le système et non la personne en vaut la peine — sinon le même incident reviendra.071Sécurité de l'équipe : là où la plupart des failles commencentMême un système sécurisé est pénétré via l'appareil d'un employé, un e-mail de phishing ou un compte sans double facteur.074Se préparer à un incident avant qu'il arrivePendant un incident, il n'y a pas le temps de décider qui décide — le papier écrit par un matin calme fait la différence entre une heure et une semaine.078Prompts : écrire une spécification, pas un sortilègeUn bon prompt définit un rôle, l'entrée, les règles de décision et la structure de sortie — et est traité comme du code, en contrôle de version et avec des tests.085Biais, équité et responsabilité dans l'utilisation des modèlesUn modèle reflète ce qu'il a vu — donc les décisions qui touchent les personnes nécessitent une vérification par segments, un humain dans la boucle et de la documentation.087Automatisation des processus : où un modèle ajoute et où il est superfluSi le processus est fixe et clair, écrivez du code ; un modèle vaut exactement là où un jugement sur du texte non structuré est nécessaire.092Revue de code qui améliore plutôt que retardeUne bonne revue est petite, rapide et centrée sur la correction et la maintenabilité — pas sur les préférences de style qu'un outil automatique devrait appliquer.093Travailler avec les versions : branches, fusions et historiqueDes branches courtes et des fusions fréquentes évitent la plupart des douleurs de version — et un historique lisible vaut l'effort le jour où on enquête sur un incident.094De la documentation que les gens lisent vraimentDocumentez ce qu'on ne peut pas déduire du code : des décisions, des limites et la façon de commencer — tout le reste vieillit et induit en erreur.095Intégrer un nouveau développeur en une semaine, pas un moisLa métrique, c'est combien de temps passe jusqu'au premier changement en production — et la plupart du délai, ce sont les accès et la configuration locale, pas la compréhension du code.098Qualité sans bureaucratie : comment ne pas casser ce qui fonctionneLes régressions sont évitées par trois choses : des tests automatiques, des publications petites et fréquentes, et la capacité de revenir en arrière rapidement.099Travailler avec des prestataires et des contractants de développementDéfinissez les livrables, la propriété et les accès par écrit à l'avance — et demandez une livraison continue, pas une grande remise à la fin.100Ce qui décide vraiment si un projet réussitPas la technologie ni la taille de l'équipe — mais la clarté de l'objectif, les courts cycles de retour et une personne responsable de décider.

Prestataires et tiers

Ce qui se passe quand vous dépendez de quelqu'un d'autre

6 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · Backend, API et données · Sécurité · Métier, qualité et équipes
006Construire, acheter ou intégrerConstruisez uniquement ce qui vous distingue ; tout le reste, achetez-le, intégrez-le ou abandonnez-le.024Passer l'examen de la boutique du premier coupLa plupart des rejets viennent des métadonnées et des autorisations, pas du code — et peuvent être évités avec une heure de préparation.041Fiabilité dans les appels aux services externesChaque appel sortant échouera à un moment donné — la seule question est de savoir si vous avez planifié ce qui se passe alors.066La chaîne d'approvisionnement du codeVotre code est une minorité de ce qui tourne en production — la plupart du risque réside dans les paquets que vous avez apportés et les outils qui les ont construits.097Choisir une technologie sans le regretter dans deux ansChoisissez selon l'équipe, la maturité et la communauté — et ce qui est ennuyeux et familier l'emporte presque toujours sur ce qui est nouveau et excitant.099Travailler avec des prestataires et des contractants de développementDéfinissez les livrables, la propriété et les accès par écrit à l'avance — et demandez une livraison continue, pas une grande remise à la fin.

Compatibilité et changement

Changer sans casser les utilisateurs existants

5 articles
Apparaît aussi dans : Applications mobiles · Backend, API et données · Infrastructure, cloud et DevOps · Métier, qualité et équipes
027Versions et compatibilité ascendante dans les applicationsLes utilisateurs conservent d'anciennes versions pendant des mois — le serveur doit les prendre en charge et savoir quand arrêter.033Versionner les interfaces : comment changer sans casserVous avez publié une interface — vous vous êtes engagé. Un changement cassant exige une nouvelle version, une période de chevauchement et un préavis.035Migrations de schéma sans temps d'arrêtModifiez le schéma en étapes compatibles ascendantes : ajoutez, remplissez, changez et seulement à la fin — supprimez.051Stratégies de déploiement : bleu-vert, canari et progressifUn bon déploiement se mesure par la capacité à revenir en arrière rapidement, pas par la vitesse de sortie.093Travailler avec les versions : branches, fusions et historiqueDes branches courtes et des fusions fréquentes évitent la plupart des douleurs de version — et un historique lisible vaut l'effort le jour où on enquête sur un incident.

Maintenance dans la durée

Ce qui arrive à un système après la fin du projet

5 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · Sécurité · L'IA en pratique · Métier, qualité et équipes
009Dette technique : quand la contracter et quand la rembourserLa dette technique est un outil de financement légitime, à condition d'être contractée délibérément, enregistrée, et d'avoir une date à laquelle on en parle.027Versions et compatibilité ascendante dans les applicationsLes utilisateurs conservent d'anciennes versions pendant des mois — le serveur doit les prendre en charge et savoir quand arrêter.066La chaîne d'approvisionnement du codeVotre code est une minorité de ce qui tourne en production — la plupart du risque réside dans les paquets que vous avez apportés et les outils qui les ont construits.090Opérer un système IA dans le tempsLes modèles se remplacent, les documents changent et les utilisateurs apprennent à poser des questions différemment — un système non touché pendant six mois est presque toujours moins bon.096Noms, structure et code vers lequel on peut revenirLe code est lu bien plus qu'il n'est écrit — donc un nom précis et une structure prévisible valent plus que n'importe quelle ingéniosité.

Expériences

Déployer progressivement et comparer les versions

3 articles
Apparaît aussi dans : Fondations produit · Applications mobiles · L'IA en pratique
002Le plus petit prototype qui prouve quelque choseUn prototype sert à répondre à une question dangereuse, pas à faire une démonstration : il a donc le droit d'être laid, manuel et incomplet.030Déploiement progressif et interrupteurs de capacitéPubliez à un petit pourcentage, observez les métriques et élargissez — et conservez la capacité de désactiver une fonctionnalité sans publier une version.088Expériences : comment savoir que le changement a amélioré quelque choseComparez deux versions sur le même trafic au même moment — toute comparaison « avant et après » mesure aussi le monde, pas seulement vous.

Interfaces

Le contrat que vous donnez à ceux qui vous consomment

4 articles
Apparaît aussi dans : Backend, API et données · Sécurité
032Concevoir une interface avec laquelle on peut vivreUne bonne interface est prévisible, cohérente et ennuyeuse — chaque surprise en elle devient une question récurrente et un bug pour celui qui l'utilise.033Versionner les interfaces : comment changer sans casserVous avez publié une interface — vous vous êtes engagé. Un changement cassant exige une nouvelle version, une période de chevauchement et un préavis.044E-mails sortants, messages et webhooksLes messages sortants sont une interface publique : ils ont besoin d'une file, de réessais et d'un enregistrement de ce qui a été envoyé à qui.065Sécuriser les interfaces publiquesUne interface ouverte à internet est scannée automatiquement dès le premier jour — supposez que chaque route sera appelée, dans n'importe quel ordre, avec n'importe quelle entrée.