La question du temps dans les architectures digitales
Conférence donnée à l’USI 2017
Architecture des APIs dans les systèmes distribués
La Blockchain et l’émergence des “distributed consensus engines”
La blockchain à la hache
Je vais y aller à la hache. Mon propos ne sera pas chirurgical, précis ; il sera assez grossier.
Grossier d’abord parce que je vais vous parler de choses qui sont émergentes et qui n’ont pas encore de formes précises mais produisent beaucoup de protentions, c’est à dire beaucoup d’attente.
Tout le monde a entendu parler du Bitcoin, ce système de transfert d’argent, mais probablement peu a entendu parler de la blockchain, qui est la technologie sous-jacente au Bitcoin.
Le Bitcoin est à la croisée de différentes technologies parmi lesquelles : les protocoles Peer-to-peer, les mécanismes de cryptographie, les systèmes de gestion de version de code, les bases de données distribuées , etc.
Même si, en apparence, il n’y a rien de nouveau, la blockchain est une réelle innovation dont les conséquences ont encore du mal à être appréhendées. Ceux qui se sont intéressés à la blockchain la comparent volontiers au web de part l’ampleur des conséquences qu’elle pourrait avoir.
De fait, il y a beaucoup de discours prophétiques à son sujet ; c’est le temps des prophéties et des prophètes de la blockchain.
Salim Ismail, qui est l’ambassadeur de l’Université de la Singularité – et qui passe son temps à cataloguer et à qualifier toutes les innovations technologiques – a déclaré, en Juillet 2015 à Paris, lors de la conférence USI : « The blockchain is THE most disruptive technology I have EVER seen ». Cela donne le ton. more »
De l’intégration des données
Une petite excursion dans les enjeux de l’intégration des données dans les systèmes distribuées à l’heure de la digitalisation.
Le gap sémantique et l’architecture orientée message
Quand on en vient à l’interaction entre des machines informationnelles, revient toujours et systématiquement la question du “semantic gap”, qui est une façon condensée de dire :
“comment deux machines peuvent-elles se comprendre sans se connaître a priori ?”
Je précise “sans se connaître a priori” car si un même concepteur doit interfacer deux systèmes, alors le gap sémantique est de facto résolu par le concepteur lui même : maîtrisant les deux machines dialoguantes, il ne fait finalement que se parler à lui-même au travers d’une répartition des tâches qu’il planifie entre deux composants logiciels.
Quatre visages des data
A l’heure où tout est data, je propose quatre visages des data selon une perspective généalogique de ce terme d’origine latine.
more »
Défaut: Architecture économie contribution Digital Studies Fiscalité
by Christian
8 comments
Remarques sur le rapport Colin & Collin sur la Fiscalité du Numérique
La question de la fiscalité met sous tension les questions numériques
Les questions relatives à la fiscalité et au droit ont une vertu évidente dans un discours sur le numérique : elles mettent sous tension ce que l’on sait, ou croyait savoir, du numérique. Réfléchir au droit du numérique où à la fiscalité du numérique offre des angles d’attaque qui permettent de hiérarchiser à la fois les questions, mais aussi de problématiser le numérique, évitant de la sorte les discours sans perspective ni dimension critique.
Avec le rapport Colin & Collin (PDF de 6 Mo) sur la fiscalité du numérique, cette tension a de toute évidence portée ses fruits et nous bénéficions à présent d’un texte de référence qui déborde largement les questions de fiscalité.
Profitons de cet appui pour commencer la discussion et y apporter un regard critique, non sans en avoir souligné auparavant sa grande qualité et sans rappeler que sa lecture n’est pas facultative. more »
La programmation au grand large
On a coutume de dire que le numérique en réseau va à la vitesse de la lumière. Cela impressionne et l’on pense qu’il y a là une réserve de vitesse telle que cela n’en fera jamais un obstacle au développement du numérique en réseau.
Services Web ou API ?
Web service & APIs
On ne parle plus beaucoup de “services web” pour désigner les communications de machines à machines sur le web. On préfère mettre en avant le terme d’API : par exemple on ne dit plus “Restful web services” mais “Restful API“.
Qu’est ce qui a changé ?
A part que cela permet à O’reilly et d’autres de rééditer les mêmes livres en changeant le titre, il n’y a apparemment pas grand chose de nouveau.
D’un point de vue générique, un service web est une API (une API qui a la particularité d’utiliser le protocole HTTP) ; et une API web serait alors le mécanisme que connaissent les développeurs (librairies, modules, classes, etc.) mais appliqué au protocole HTTP.
Interface ou Protocole ?
Les choses paraissent donc simples, mais elles ne le sont pas forcément si on y prête bien attention. more »
Défaut: Architecture CoSQL Métadataware métastabilité Meijer programmation
by Christian
19 comments
Sens et enjeux des modèles de stockage et d’accès aux données
C’est typiquement le genre d’article qui nécessite des corrections, des remarques et peut-être un débat. Alors n’hésitez pas.
Code et data
Pas de code sans données, car le but d’un code est de tourner et de produire des résultats et, pour ce faire, le code doit “manger” des données.
On peut voir le code dans sa forme la plus abstraite comme un algorithme dont le rôle serait de produire des preuves. Mais on peut aussi voir le code comme un algorithme qui ne fait pas simplement que valider et prouver mais également qui produit des changements d’états et des évènements qui, au sens littéral du terme, changent le monde.
On a ici un parallèle avec les “speech acts” de Searle et Austin dont Henry Story avait parlé dans son intervention au MeetUp Semantic Web de Février 2011.
Quiconque écrit un programme s’attend en effet à “changer le monde”, ne serait-ce que pour écrire “Hello World” sur un terminal. Changer le monde avec des algorithmes et du code, Microsoft, Google, Facebook et d’autres l’on fait, et l’ensemble des développements en Open Source peut-être plus encore.
Pas de code sans données donc. Or ces données sont stockées dans des supports de mémoires différents selon qu’elles sont en mémoire vive, sur un système de fichier, ou dans une base de donnée. Et chaque support de mémoire utilise un modèle de données qui n’est pas forcément le même. Ce qui nous ramène à la difficile collaboration entre les développeurs et les gestionnaires de base de données.
Si les développeurs et les administrateurs de base de données doivent collaborer, la réalité est parfois toute autre : les développeurs ne comprennent pas toujours le SQL et les RDB (bases de données relationnelles), et les DBA (administrateurs de base de données) ne voient les développeurs que comme de dangereux cowboys qui veulent massacrer l’intégrité de leur données (“mon précieux …”).
Le DBA
Le développeur
