Dan Garlasu, dgarlasu@yahoo.

com
Objectif général du sujet  Développer des capacités d'utilisation efficace
de divers langages de programmation et
architectures afin de concevoir et de
développer des applications logicielles
Objectifs spécifiques  Comprendre les principes des différents types
de langages de programmation et ce qu'il faut
savoir pour programmer efficacement dans un
langage spécifique. À cet égard, il existe trois
composants cruciaux : le paradigme du
langage, la syntaxe et la sémantique.
 L'établissement et l'utilisation de principes
solides d'ingénierie afin d'obtenir
économiquement un logiciel fiable et
fonctionnant efficacement sur de vraies
machines
Activité Critère d'évaluation Méthodes d'évaluation Poids dans la
note finale
Connaissance du Questionnaire de 30 questions
contenu du didacticiel choisies au hasard dans une
Cours (2h/semaine) base de connaissances.
50%

Séminaire Devoir individual

No. 1 25%
(1h/semaine)
Devoir individual
Laboratoire
No. 2 25%
(1h/semaine)
Norme minimale de performance
 60% de présence au cours
Paradigmes de Programmation
Cours #1, 1eme Partie
Six Décennies de Génie Logiciel

Dan Garlasu, dgarlasu@yahoo.com

Source: Mary Poppendieck
Six Decades of Software Engineering (infoq.com)
 Les Années 60 - La Technologie était Primitive
• 1964 - Annonce du modèle IBM 360
• 1965 – 1-er SCE pour télécom
• 1968 - La crise du logiciel
• 1969 - Apollo se pose sur la Lune
1er Système de Commutation Electronique (SCE),
Schenectady, NY

Ordinateur de guidage de la mission Apollo

Dans les années 60, la technologie était vraiment primitive!

En haut à droite: circuit intégré d'IBM 360.
Côté supérieur gauche: le premier système de commutation électronique installé à New York en 1965. Jusque-là, les
systèmes PBX étaient basés sur des relais!
La crise logicielle est un terme utilisé aux débuts de l'informatique pour désigner la difficulté d'écrire des
programmes informatiques utiles et efficaces dans le temps requis. ... Le terme a été inventé par certains
participants à la première conférence de l'OTAN sur le génie logiciel en 1968 à Garmisch, en Allemagne. Les causes
de la crise logicielle étaient liées à la complexité globale du matériel et du processus de développement logiciel. La
crise s'est manifestée de plusieurs manières:
• Projets en cours de dépassement de budget
• Projets en cours d'exécution
• Le logiciel était très inefficace
• Le logiciel était de mauvaise qualité
• Les logiciels ne répondaient souvent pas aux exigences
• Les projets étaient ingérables et le code difficile à maintenir
• Le logiciel n'a jamais été livré en certain projets
Ordinateur de guidage Apollo (Apollo Guidance Computer) - L'AGC a une longueur de mot de 16 bits, avec 15 bits
de données et un bit de parité. La plupart des logiciels sur l'AGC sont stockés dans une mémoire spéciale en lecture
seule façonnée en tissant des fils à travers et autour des noyaux magnétiques, bien qu'une petite quantité de
mémoire centrale en lecture / écriture soit disponible. Les astronautes communiquaient avec l'AGC en utilisant un
affichage numérique et un clavier appelé DSKY (pour «affichage et clavier», prononcé «DIS-kee»). L'AGC et son
interface utilisateur DSKY ont été développés au début des années 1960 pour le programme Apollo par le
laboratoire d'instrumentation du MIT et ont volé pour la première fois en 1966. L'AGC était le premier ordinateur
basé sur des circuits intégrés en silicium. Les performances de l'ordinateur étaient comparables à celles de la
première génération d'ordinateurs personnels de la fin des années 1970, comme l'Apple II.
 Thèmes Des Années 1960:

L'architecture compte
• Nouvelle architecture <=> innovation révolutionnaire

Loi de Conway (1968)

• Architecture système <=> Architecture organisationnelle

Fiabilité à grande échelle

• Redondance + Isolement + Responsabilité locale

Donc, si vous jetez un œil aux années 60, voici les principaux thèmes:
• L'architecture est importante, car les nouvelles architectures semblent être à l'origine
d'une innovation de rupture.
• En 1968, la loi de Conway stipule que l’architecture du système informatique et
l’architecture organisationnelle sont les mêmes, et vous cherchez donc à faire en sorte
que cela fonctionne (les organisations conçoivent des systèmes qui reflètent leur propre
structure de communication).
• L'autre chose, si vous regardez Internet qui est la définition de la fiabilité à grande échelle,
il y a trois principes fondamentaux:
1. Redondance
2. Les isolations garantissent que vous ne rencontrez pas de pannes en cascade
3. La responsabilité locale signifie que l'hôte est responsable, et non un élément du
réseau proche du responsable.
 1970: ARPANET Repense l’Architecture Réseau

1971: ARPANET 1972: Louis Pouzin (France)

Les compagnies de téléphone nationales ne
voulaient prendre en charge l’échange de données.

Rendre les hôtes responsables

de l'échange de données

CYCLADES
1974 : TCP/IP

Computer History Museum

Vinton Cerf et Robert Kahn (États-Unis)
• Chaque réseau distinct est autonome, aucune
modification interne n'est requise.
• Aucune information conservée par les
passerelles et les routeurs. Pas de contrôle
global au niveau des opérations.
• Communications dans la mesure du possible.

C'est le précurseur de ce qui est devenu Internet: Arpanet.

Ce que vous voyez dans l'image comme des IMP (Interface Message Processors),
spécifiquement conçus pour faire le traitement des messages, en fait un système de
commutation pour les messages informatiques. Pour connecter n'importe quel ordinateur au
réseau, vous aviez besoin d'un IMP devant lui pour pouvoir parler. Ils étaient vulnérables à
l'échec.
Il y a eu des discussions pour étendre Arpanet et Louis Pouzin de la France a informé que la
conception américaine ne convient pas à l'Europe puisque les compagnies de téléphone
nationales ne changeront pas de données. Il a conseillé un modèle différent dans lequel les
hôtes sont responsables de l'échange de données. Il a en fait mis sur pied un réseau appelé
Cyclades. Il a été suffisamment réussi pour que, lorsqu'en 1974 Vinton Cerf et Robert Kahn
ont proposé le protocole TCP / IP, ils ont en fait modelé la structure du réseau des Cyclades.
Années 1970 : XEROX Parc développe le Bureau Numérique

Dans les années 1970, Xerox PARC a été lancé dans le but de concevoir le bureau du futur.
Bien que Xerox ait son siège sur la côte Est des États-Unis, ils ont décidé de placer les
chercheurs en Californie, sur la côte ouest où ils ne seraient pas influencés par la direction de
l'Est (il en a été de même pour IBM lorsqu'ils ont lancé le projet IBM PC). Et ils étaient
vraiment productifs. Ils ont conçu l'interface graphique, les affichages bitmap, l'édition de
WYSIWYG (what-you-see-is-what-you-get), ils ont inventé les fenêtres qui se chevauchent, la
souris, les menus, les icônes. Ils ont inventé l'informatique interactive: le premier ordinateur
personnel, la publication assistée par ordinateur, l'impression laser, Smalltalk (lorsque Agile a
été lancé dans les années 2000, presque tous les premiers utilisateurs étaient des
Smalltalkers - car Smalltalk était un langage qui encourageait une manière agile de penser les
logiciels). Enfin, ils ont inventé Ethernet. Donc, ils ont inventé toutes ces choses merveilleuses
mais n'ont pu commercialiser aucune mais une de celles-ci: l'imprimante laser, car c'était un
objet plus proche de ce qu'ils vendaient déjà: des copieurs.
 Thèmes des années 1970 :
L'ingénieur responsable
• Les ingénieurs sont responsables de la conception et du
développement d'un composant et de s'assurer que leur
composant fonctionne correctement et fait son travail dans le
cadre du système global.

Conception résiliente
• Tout ce qui peut mal tourner finira par mal tourner.

Programmation structurée
• «Si vous voulez des programmeurs plus efficaces, vous auriez
découvrir qu'ils ne devraient pas perdre leur temps à déboguer - ils ne
devraient pas introduire de bogues pour commencer» *
* Edsger Djikstra

Et voici les thèmes des années 70.

• L'ingénieur en informatique a la responsabilité de vraiment comprendre le problème qu'il
essayait de résoudre et de comprendre également son rôle dans l'ensemble du système.
• Vous devez concevoir de manière à ce que lorsque tout ce qui peut mal tourner finit par
mal tourner, votre système devrait quant meme fonctionner!
• Programmation structurée, correctement introduite par Dijkstra
 Années 1980: programmation par l’utilisateur

• Ordinateur personnel Les ordinateurs personnels sont arrivés chez nous

• Traitement de texte
• Feuilles de calcul
• Langues de 4e génération
• Générateurs de rapports

Alors, pourquoi avons-

nous besoin de
programmeurs ?

Les langages de niveau

supérieur permettent des
niveaux de complexité plus
élevés

Les années 1980 ont été l'époque où les ordinateurs personnels ont été inventés et les
applications d’adoption massive (killer apps) étaient les traitements de texte et des feuilles de
calcul.

En même temps, il y avait les langages 4GL qui généraient des rapports et ils étaient vraiment
bons au début, de sorte que les gens ont commencé à se demander: pourquoi avons-nous
plus besoin de programmeurs?

Eh bien, nous sommes toujours là, et la raison est que chaque fois que vous passez à un
langage de niveau supérieur, vous passez simplement au niveau de complexité suivant, les
problèmes que vous résolvez sont plus complexes, donc, c'est juste un autre niveau
d'abstraction, mais vous devez toujours faire face à la complexité quelle que soit la couche sur
laquelle vous travaillez.
 Thèmes des années 1980 :
L'exécution compte
• L'expertise, la concentration et l'attention portée aux
détails sont essentielles pour la fiabilité, l'évolutivité,
convivialité, la sûreté, la sécurité...

Focus sur les flux

• Ne sous-optimisez pas. Gérez le débit, pas les tâches.

Loi de Parkinson (pour les logiciels)

• La complexité s'étend pour s'adapter à la dernière abstraction

Donc, ce que nous avons appris dans les années 1980 :

Lorsque vous travaillez dans un environnement d'entreprise, des éléments tels que
l'expertise, la concentration, l'attention portée aux détails sont des éléments essentiels
pour la fiabilité, l'évolutivité, la convivialité, la sûreté et la sécurité. C'était une question
d'exécution et c'était vraiment intéressant de voir comment cela fonctionnait réellement.
Concentrez-vous sur le flux - ne sous-optimisez pas, car lorsque vous vous concentrez
sur l'efficacité des ressources individuelles, vous sous-optimisez fondamentalement
l'ensemble de votre système. Vous devez gérer la vitesse à laquelle les choses se
déplacent dans votre système, pas l'achèvement des tâches, et lorsque vous faites
cela, vous obtenez un bien meilleur système.
Et puis il y a la loi de Parkinson qui dit : la complexité s'étend pour s'adapter à la
dernière abstraction.
 Années 1990 : architectures client-serveur

Une base de données Transactions type ACID

unique et intégrée

Appareils de présentation Serveurs d'applications Serveur de base

de données

Sur un seul serveur.

Dans les années 90, vous aviez des appareils de présentation (périphériques frontaux), puis
des serveurs d’applications et une base de données attachée à un gros serveur en arrière-
plan.
Pourquoi a-t-on besoin d'un serveur de base de données? Parce que si vous faisiez un
traitement de transaction comme la plupart des applications le faisaient dans un centre de
données à ce moment-là, vous avez besoin d'un ensemble de propriétés ACID (Atommicity,
Consistency, Isolation, Durability) et si vous n'aviez pas de base de données, vous ne pouviez
pas avoir de transactions ACID, par conséquent, vous ne pouviez pas maintenir un système
d'enregistrement valide. Et cela était situé sur un seul serveur, et la raison était due au
théorème CAP (Consistency, Availability, Partitioning), ce qui signifie que vous ne pouvez pas
avoir cohérence, disponibilité et partitionnement en même temps. Donc, évidemment, vous
voulez de la cohérence et évidemment vous voulez de la disponibilité. Vous ne pouvez donc
pas procéder au partitionnement dans cette architecture.
Cependant, après 2001, lorsque certains des événements les plus dramatiques ont eu lieu, le
concept de cohérence éventuelle a permis aux gens de réfléchir de manière agressive au
partitionnement (en termes de théorème PACELC ca veut dire: Partitioning, Availability,
Consistency, else Latency and Consistency).
 Années 1990 : un processus de livraison typique

Commencer à travailler Mise en

sur la version production
Cycle de publication typique
6 à 18 mois

\ \
I
Blocage typique du code
pour les tests : 30 %
Blocage typique des fonctionnalités
7 à 24 mois avant la sortie du
Parfois: 50 %
nouveau logiciel

Un processus de livraison de logiciel typique dans les années 90 ressemblait à ceci:

• Le cycle de publication typique était de 6 à 18 mois, et généralement vous avez
commencé le gel du code pour les tests dans les 30%, parfois 50% de ce cycle.
• L'autre chose intéressante est qu'avant de commencer à travailler sur la version, vous
faites un gel des fonctionnalités 7 à 24 mois avant la sortie.

Vous avez donc eu un temps extrêmement long entre la définition des exigences et la
publication de quelque chose.

Et donc nous allons au cœur de la raison pour laquelle nous utilisons Agile aujourd'hui.
 Les années 1990 : une transformation du génie logiciel

 Eric Raymond : « La Cathédrale et le Bazar » 1997; 1999

Cathédrale Bazar

Comment un bazar pourrait-il fonctionner pour le génie logiciel ?

L'article d'Eric Raymond a changé le paradigme: la cathédrale signifie une architecture

monolithique unique et sa réalisation prend des siècles. Le bazar de l'autre côté ressemble à
une sorte de gâchis, mais vous pourriez faire des choses en une semaine seulement.

Donc, dans le bazar, il y a toutes ces petites équipes qui travaillent de manière indépendante,
en compétition les unes contre les autres. Il y a beaucoup de redondance ici, il y a beaucoup
de gens qui exécutent des activités non coordonnées et la question ici est: comment un bazar
(qui est Open Source) pourrait-il fonctionner pour le génie logiciel? Mais cela a fonctionné et
nous savons que cela a fonctionné car cela vous a apporté un nombre illimité de ressources
pour résoudre des problèmes qu'une équipe dédiée, travaillant sur une cathédrale, ne pourrait
peut-être pas faire.
Les Années 1990 : l’Essor Improbable de l’Open Source

• 1991 - Linux • 1999

Un étudiant d'Helsinki écrit un IBM investit 1 milliard
système d'exploitation "Just for de dollars dans Linux
Fun".

• 1993 - WWW • 1999 lH E

• Un groupe de huit développeurs a

commencé à améliorer le serveur Web
APACHE
S O F T W A R E F O U N D A T IO N
NCSA HTTPd
• Tim Berners-Lee à connecte des
utilisateurs d'ordinateurs ensemble, en
développant le World Wide Web sur la Apache est utilisé par >40 % de
machine NeXT de Steve Jobs dans
quelques mois tous les sites Web en 2020.

Et donc nous avons eu dans les années 1990 la montée improbable de l'Open Source:
• En 1991, nous avons Linux.
• En 1993, un groupe de développeurs de l'Université de l'Illinois à Urbana-Champaign a
examiné les hyperliens et a créé un serveur Web capable de le faire. En tant que tel,
NCSA HTTPd est un serveur Web précoce, maintenant abandonné, développé à l'origine
par Robert McCool et d'autres. Sorti pour la première fois en 1993, il figurait parmi les
premiers serveurs Web développés, après le CERN httpd de Tim Berners-Lee, le serveur
Plexus de Tony Sanders et quelques autres. En fait, Tim Berners-Lee à développé le
World Wide Web sur la machine NeXT de Steve Jobs dans quelques mois.)
• En 1999, IBM investit un milliard $ dans Linux et en parallèle, la fondation Apache a été
créée. Apache est actuellement utilisé par plus de 40% des sites Web dans le monde.
• Finalement, il y a quelques années, IBM a acheté RedHat pour 30 milliards de dollars !!!
 Thèmes des Années 1990
La Cathédrale : processus standard
• "Planifiez le travail et travaillez le plan".

Le bazar : logiciel libre et ouvert

• Pas de processus, pas de plan, responsabilités locales, meilleur
logiciel !

Préparation à l'an 2000

• Le monde s'effondrera probablement quand la date = 2000.

Voici donc les thèmes des années 1990:

• La cathédrale: planifier les travaux et élaborer le plan. Il s'oppose au Bazar: logiciel libre et
ouvert. Comment ça marche? Aucun processus, aucun plan, il y avait une responsabilité
locale, il y avait des commetteurs, et pourtant vous avez obtenu de meilleurs logiciels.

• Et puis les années 1990 ont été totalement consommées par l'an 2000 parce que tout le
monde pensait que le monde allait s'écrouler quand l'an 2000 viendra! Eh bien, ce n'est
pas le cas, mais vous avez beaucoup de gens qui ont consommé le plus d'énergie de la
communauté informatique pour trouver comment y remédier.

• Et en même temps, vous avez les nouveaux enfants sur le bloc comme Google et
Amazon que les gens ignoraient l’apparition, parce qu’ils étaient consommés par la
problème de l'an 2000.
 Années 2000 : la décennie des équipes et des
« logiciels fonctionnels »

An 2000 - Explication de la
programmation extrême est
fournie par Kent Beck

2001 Manifeste Agile

Ok, alors l’an 2000 s’est passé sans aucun désastre et puis nous avons la première décennie
des années 2000, qui s’appelle la décennie des équipes.

Il a été lancé par le livre « Extreme Programming » de Kent Beck (la programmation extrême
(XP) est une méthodologie de développement logiciel qui vise à améliorer la qualité du logiciel
et sa réactivité face à l'évolution des exigences des clients).

Puis vous avez le Manifeste Agile, qui disait: "parlons des logiciels fonctionnels".
Pour Agile, nous consacrerons environ une demi heure plus tard aujourd’hui. Mais avant de
passer au Agile je vais finir avec les deux décades qui nous restent a revoire.
Thèmes des années 2000:

Des équipes multidisciplinaires

• La coordination entre les disciplines est la partie la plus difficile.

Livraison incrémentielle
• Les grands projets et les longs cycles de publication - synonymes
de professionnalisme - sont tombés en disgrâce.

Proxies
• "Représentant client" - "Propriétaire de produit" - "L'entreprise"

Alors, je vais parler des thèmes des années 2000:

• Nous nous sommes vraiment bien débrouillés dans les équipes multidisciplinaires, car il
était bien entendu que la communication entre des équipes de type cloisonné était très
difficile, donc, au lieu de cela, vous organisez des équipes multidisciplinaires où les gens
ont encore une discipline, mais donc la coordination de leur activité est beaucoup plus
facile.
• Avec la livraison incrémentielle, nous devons accélérer considérablement la livraison des
projets.
• Une autre chose qui s'est produite est l’apparition les « Proxies » (mandataires,
intermédiaires, interposes), et c'est la pire chose qui se soit produite. À la fois
représentant du client, propriétaire du produit, représentant du métier,… tous ces gens qui
disent à l'équipe d'ingénierie ce qu'il faut faire. Et ce fut probablement la pire erreur de
cette décennie.
 Années 2010 : La Décennie Du Flux

Et puis nous avons la décennie des Flux à partir de 2010, avec le concept de livraison
continue et d'intégration continue et la philosophie DevOps.
Cela nous ramène au concept de programmation structuré, mais de manière beaucoup plus
rapide et en utilisant de meilleurs outils. Et c'est en fait le développement des outils pour le
« pipeline » de livraison continue qui a rendu possible la façon dont nous élaborons les
logiciels aujourd'hui. Et cela a vraiment changé la manière de faire du logiciel en termes de
«Comment puis-je livrer cette chose immédiatement» ou «Comment puis-je automatiser cette
chose»…
 Le plus gros goulot d'étranglement : les dépendances

Alors, quel est le plus gros goulot d'étranglement pour que cela fonctionne? Le plus gros
goulot d'étranglement pour tout type de livraison continue sont les dépendances, que je vais
expliquer dans la diapositive suivante.
 Attaquer le problème de dépendance

 L'architecture d'entreprise  Architecture de microservices

 "Vou s le c o ns tru is ez , v ou s le p os s é de z !"

Data

Appl ication

Tech nology

Si vous regardez comment attaquer le problème des dépendances, voici l’architecture

d’entreprise des années 90 et le point le plus important était qu’il n’y avait qu’un seul système
d’enregistrements. Et c'était la base de données, c'était un générateur de dépendances massif
car si vous voulez modifier quelque chose au niveau de l'application, vous devez regarder les
données et cela peut avoir un impact sur toutes les autres applications dépendantes de ces
données, ce qui peut rendre le flux impossible. C'est ainsi que l'idée d'une architecture de
microservices est née, et nous sommes donc arrivés à une plate-forme technologique comme
les petits magasins de données distribués, lancés pour la première fois par Amazon, et
lorsqu'ils sont apparus pour la première fois, beaucoup de gens n'y croyaient pas parce ils ont
été utilisés avec le fait que de nombreuses transactions doivent être contenues dans une seule
base de données tandis que la nouvelle architecture distribue toutes les banques de données
sur tous leurs services. Cependant, ce type d'architecture a pour principal intérêt qu'ils
n'interagissent que de manière fédérée et qu'il y a l'isolement qui le rend très évolutif de la
même manière que l'Internet le fait.
 Comment plusieurs petites équipes peuvent-elles
collaborer pour accomplir un projet ensemble?

Le modèle de l'ingénieur responsable

Comment résoudre le problème: nous avons donc tous ces microservices, et la question est
de savoir comment faire travailler ensemble un groupe de petites équipes pour accomplir leur
mission globale?
Et ici l'analogie qui a été proposée est de la regarder de la façon dont Space X est construit.
Dans la diapositive, vous avez une fusée Falcon 9, avec différents modules couplés entre eux
et l'idée générale ici est celui de l'ingénieur responsable, ce qui signifie que l'équipe qui est
responsable, disons de la charge utile, a tout le nécessaire pour faire son travail. Donc, si vous
regardez Space X, ils n'ont pas de département logiciel, mais ils ont toutes les ressources
nécessaires pour faire fonctionner tous les moteurs. Ainsi, chaque composant a une équipe
avec un ingénieur en chef responsable et c’est la responsabilité de l'équipe de comprendre la
tâche suivante, l'objectif, l'ensemble du système et toutes les choses nécessaires pour faire sa
part dans la mission globale.
Thèmes des Annees 2010:

 Infrastructure en tant que code

 Le cloud : les centres de données deviennent un utilitaire

 Rompre les dépendances

 Architecture "Smartphone"
 Déploiement indépendant

 L'équipe responsable
 Les équipes sont responsables de la conception, du développement et du
bon fonctionnement d'un composant, ainsi que de la compréhension et de
l'accomplissement du travail de ce composant dans le système global.
Comment se prépare-t-on pour les événements « Black Swan » ?
Conception pour la résilience
• Redondance
• Isolement
• Contrôle local

Donc, dans 2020 tout a changé a cause du COVID au bout d'une seule semaine: le 15 mars
2020 et d’ici vous connaissez toute l’histoire...

Et la question est: comment se préparer pour les événements de type « Black Swan » (aka
désastres)? Et c'est sur ce sur quoi nous nous concentrons maintenant parce-que cela ne va
pas disparaître de sitôt.

Et nous pouvons utiliser cet exemple d'Islande où les volcans, lorsqu'ils explosent, font fondre
les glaciers et génèrent des lacs remplis d'eau qui détruiront les ponts. Et cela tourne encore
et encore. Donc, en Islande, la décision a été qu'au lieu de construire grand et plus grand, ils
n'allaient pas reconstruire à nouveau, mais plutôt concevoir pour la résilience. Et vous devez
construire avec la redondance à l'esprit, et la prochaine chose est que vous devez isoler les
choses, donc si un pont s'éteint, vous n'avez pas à reconstruire toute la route mais juste le
pont. Et vous devez avoir un contrôle local car lorsque le système central meurt, vous ne
voulez pas que tout meure.
Organisés pour la résilience
 Petites équipes multidisciplinaires Maintenir une conversation
 Tous impliqués dans le plaisir des clients bidirectionnelle continue
 Clair : Objectif - Résultats – Contraintes avec le marché
 Liberté d'action
 De manière asynchrone, sans autorisation

 Responsable de la construction de la bonne chose

 Philosophie de la responsabilité

 Livraison fréquente aux clients

 Apprenez la voie à suivre

 Succès = résultats client

 Pas de sortie, pas de intermédiaires!

L'autre chose que vous devez faire est de vous organiser pour la résilience. Et ceci est inspiré de ce livre que
vous voyez sur la diapositive: « Sense and Respond ». Ca veut dire: pas seulement de planifier et de construire,
mais de ressentir, d'écouter et d'être capable de réagir très rapidement. En d'autres termes: maintenir une
conversation continue dans les deux sens avec votre marché. Il faut donc se structurer en petites équipes
multidisciplinaires impliquant tout le monde pour ravir le client: les gens du produit, les gens des applications,…
tout le jeu. Si vous jetez un œil aux équipes AWS, ce sont des équipes complètes, impliquant toutes les
personnes nécessaires pour que le service soit opérationnel. Les équipes ont besoin d'objectifs clairs,
comprennent quels sont les désirs des clients, pas les tâches, et elles ont besoin de savoir quelles sont les
contraintes, par exemple si elles doivent livrer en 3 jours, 3 semaines ou 3 mois. Les équipes doivent être libres
d'agir de manière asynchrone et sans l'autorisation de la direction car elles ont un objectif clair et comprennent
les résultats du succès et elles n'ont pas besoin d'autorisation pour essayer des choses et déterminer ce qui
fonctionne, et elles n'ont pas non plus besoin de l'autorisation de leur collègues. C'est donc un problème
d'architecture car la liberté d'agir signifie que l'architecture vous permet de le faire. L'équipe trouve la solution,
elle n'est pas imposée.
Nous avons besoin d'une livraison fréquente aux clients afin que vous appreniez votre chemin à mesure que
vous ressentez et réagissez.
Le succès doit commencer à signifier des résultats pour les clients, pas des sorties (combien de tâches sont
effectuées) et certainement pas des mandataires (Proxies) en vous vous disant: Oui, c'est bien!