Idée → Système

Le chemin d'une idée vers un système qui fonctionne.

Une bibliothèque de connaissances sur le développement, l'infrastructure, la sécurité et l'IA. Chaque article s'ouvre sur un résumé en une ligne, se poursuit en langage clair pour qui n'a jamais construit un tel système, et se termine par un encadré « Pour aller plus loin » consacré aux décisions techniques.

Voir la bibliothèquePrincipes de lecture

Trois règles qui reviennent dans chaque article

Les outils changent chaque année. L'ordre des décisions, non.

1

Le problème d'abord, l'outil ensuite

Choisir une technologie avant d'avoir défini le problème est un pari qui coûte des mois.

2

Des preuves avant l'engagement

La semaine la moins chère pour découvrir votre erreur est la première, pas le sixième mois.

3

Ce qui n'est pas mesuré ne s'améliore pas

Sans mesure, tout changement relève de la croyance, et tout débat est tranché par la voix la plus forte.

La bibliothèque

100 articles dans huit domaines. Cherchez, filtrez, ou faites simplement défiler.

Fondations produit

D'une idée à une définition sur laquelle on peut bâtir

12 articles
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.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.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.

Web et frontend

Sites et applications dans le navigateur

8 articles
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.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.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.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.

Applications mobiles

De la boutique d'applications au correctif urgent

11 articles
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.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.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.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.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.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.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.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.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.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.

Backend, API et données

Le côté que personne ne voit et que tout le monde ressent

15 articles
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.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.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.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.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.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.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.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.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.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.

Infrastructure, cloud et DevOps

Comment le code passe en production et y reste

14 articles
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.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.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é.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.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.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.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.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.

Sécurité

Penser comme un attaquant avant qu'il ne le fasse

14 articles
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.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.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.

L'IA en pratique

D'un modèle à un système qui fonctionne

16 articles
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.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.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.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.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.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.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.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.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.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.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.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.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.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.

Métier, qualité et équipes

Ce qui transforme du code en travail professionnel

10 articles
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.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.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é.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.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.

À propos de Boomalaya

« Boom », c'est l'instant où une idée rencontre la réalité — et les ondes qui suivent sont le vrai travail. Boomalaya est un endroit pour apprendre ce chemin : pas une liste d'outils qui change chaque mois, mais un ordre de décisions qui reste juste même quand la technologie en dessous évolue.

Nos applications

Boomalaya est aussi un studio iOS. Ces trois applications reposent sur les principes décrits dans les articles : traitement sur l'appareil, pas de serveurs, pas de compte, pas de traçage.

MonoBand: AI Stem Splitter

Transforme n'importe quel morceau que vous possédez en studio de travail et de remix — entièrement sur l'appareil, sans internet ni abonnement.

  • Séparation en 6 pistes par un modèle d'IA qui tourne sur l'appareil : voix, batterie, basse, guitare, piano et autres
  • Outils de travail : transposition, changement de vitesse sans changer la hauteur, boucle A→B, et détection automatique des accords, du tempo et de la tonalité
  • CarPlay : karaoké en un geste, et couper ou isoler n'importe quel instrument en conduisant
  • Pas de serveurs, pas d'analytique, pas de compte — vos morceaux et vos enregistrements ne quittent jamais l'appareil

Gratuit · Musique · iPhone, iPad, Mac · 8 langues

Sur l'App StoreEn hébreu
MonoBand: AI Stem Splitter — Produce music beats like prosMonoBand: AI Stem Splitter — On device. Offline. Yours.MonoBand: AI Stem Splitter — Isolate any part and play it yourselfMonoBand: AI Stem Splitter — Sing or play and record on topMonoBand: AI Stem Splitter — Drill any section till you nail itMonoBand: AI Stem Splitter — Playlists that play back-to-backMonoBand: AI Stem Splitter — On-device AI, no internetMonoBand: AI Stem Splitter — Record vocals over the song

Block AI

Un puzzle de blocs classique avec une progression construite par IA — tourne en local, sans publicité ni compte.

  • Mode aventure avec 100 niveaux générés par IA
  • Difficulté adaptative qui réagit à votre façon de jouer
  • Un coach IA qui analyse habitudes, erreurs et points forts
  • Quatre modes de jeu : puzzle quotidien, course infinie, contre-la-montre et aventure

Gratuit · Puzzle · iPhone · Classements Game Center

Sur l'App StoreEn hébreu
Block AI — Block AI home screen and game modesBlock AI — Block puzzle gameplayBlock AI — Adventure stage previewBlock AI — AI building the Adventure stagesBlock AI — AI Coach analysisBlock AI — Play statisticsBlock AI — Stage clearedBlock AI — How to play

AIKeyMoji: AI Sticker Keyboard

Un clavier qui transforme n'importe quelle photo ou vidéo en autocollant personnel, avec une IA qui tourne sur l'appareil lui-même.

  • Photo → l'IA retire l'arrière-plan → un autocollant net, en quelques secondes
  • Prenez une image dans une vidéo, ou un autocollant animé de trois secondes
  • 728 autocollants animés intégrés dans dix catégories, avec recherche en direct
  • Fonctionne dans toute application où vous tapez ; pas de serveurs, pas de traçage, pas de compte

Gratuit · Graphisme et design · iPhone, iPad · Anglais et hébreu

Sur l'App StoreEn hébreu
AIKeyMoji: AI Sticker Keyboard — Stickers from anythingAIKeyMoji: AI Sticker Keyboard — Send from any chat, one tapAIKeyMoji: AI Sticker Keyboard — Five ways to make a stickerAIKeyMoji: AI Sticker Keyboard — Video to animated stickerAIKeyMoji: AI Sticker Keyboard — 728 stickers, organizedAIKeyMoji: AI Sticker Keyboard — Your photos stay private

Boomalaya · App Store

Nous contacter

Une question, une correction ou une idée d'article — écrivez-nous.

Support@boomalaya.com