<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Fractional CTO</title><link>https://fractionalcto.es/fr/tags/architecture/</link><description>Recent content in Architecture on Fractional CTO</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Mon, 23 Mar 2026 17:59:59 +0100</lastBuildDate><atom:link href="https://fractionalcto.es/fr/tags/architecture/feed.xml" rel="self" type="application/rss+xml"/><item><title>La relation entre l'organisation des équipes et l'architecture applicative</title><link>https://fractionalcto.es/fr/la-relation-entre-lorganisation-des-equipes-et-larchitecture/</link><pubDate>Fri, 04 Aug 2023 12:06:03 +0000</pubDate><guid>https://fractionalcto.es/fr/la-relation-entre-lorganisation-des-equipes-et-larchitecture/</guid><description>&lt;p&gt;Cette relation est connue sous le nom de loi de Conway, \u00e9nonc\u00e9e par Melvin Conway en 1967 : \u00ab Les organisations qui con\u00e7oivent des syst\u00e8mes [&amp;hellip;] sont limit\u00e9es \u00e0 produire des conceptions qui sont des copies des structures de communication de ces organisations. \u00bb&lt;/p&gt;
&lt;p&gt;La communication au sein de l&amp;rsquo;\u00e9quipe est fr\u00e9quente et fluide, avec des r\u00e9unions de planification r\u00e9guli\u00e8res, des dailies, des r\u00e9trospectives et des d\u00e9mos. Cela permet \u00e0 l&amp;rsquo;\u00e9quipe d&amp;rsquo;avoir un haut niveau d&amp;rsquo;alignement et une coordination agile, ce qui est fondamental pour le d\u00e9veloppement d&amp;rsquo;un composant. Si vous d\u00e9cidez soudainement de diviser cette \u00e9quipe en 2 \u00e9quipes, il y a une rupture dans la communication. La communication avec les autres \u00e9quipes est beaucoup moins fr\u00e9quente, car l&amp;rsquo;une des id\u00e9es des \u00e9quipes est de les isoler des facteurs externes afin qu&amp;rsquo;elles puissent se concentrer sur leur p\u00e9rim\u00e8tre. Cette r\u00e9duction de la communication entre les \u00e9quipes rend la t\u00e2che de maintenir un seul composant plus complexe. Dans ces cas, il y a deux options : 1) Diviser le composant en 2, un par \u00e9quipe, ce qui permet aux \u00e9quipes de se d\u00e9coupler et de travailler de mani\u00e8re plus autonome. 2) Maintenir un seul composant, ce qui implique la mise en place d&amp;rsquo;une s\u00e9rie de m\u00e9canismes de coordination et de r\u00e9unions entre les \u00e9quipes, avec la surcharge que cela entra\u00eene. De plus, les \u00e9quipes sont interd\u00e9pendantes, ce qui r\u00e9duit la vitesse et l&amp;rsquo;autonomie et affecte la productivit\u00e9 (puisqu&amp;rsquo;elles doivent travailler si \u00e9troitement ensemble, on pourrait presque dire que, pour des raisons pratiques, il n&amp;rsquo;y a toujours qu&amp;rsquo;une seule \u00e9quipe).&lt;/p&gt;</description></item></channel></rss>