Pragmatism - DevOps - CloudNative - .NET

If you would like to have us live in a conference or a community meetup, please contact us.


Git Tips and Tricks

Any developper working within a team spend a lot of time collaborating with other team members. Git is the most used source control respository and can help you a lot in the productivity space.

Docker Introduction

Containers are everywhere. Working with them requires to know a bit more on the underlying infrastructure running you code. This talk can help you understand the basics.


Versioning your code base and your assemblies or artefacts is quite important for multiple reasons : Debugging
Communicating changes

But how can you automate that in a DevOps way? Let's share some strategies to get your team on track.

WebAssembly in the .NET World

WebAssembly (WASM) is the next disruptive technology in the software area. A lot of work is going on in the .NET ecosystem to embrace this new technology. Blazor, Uno Platform, and more Open Source projects.

Will WASM replace containers?


Team Topologies

Based on the reading of Team Topologies : Organizing Business and Technology Teams for Fast Flow, a French technical podcast discussing how the book can be helpful in enterprise when trying to make a cultural change.

Link :

June 8th, 2020


Microservices Design Patterns

Microservices are an architectural consequence following Agile, DevOps and DDD. Based on these movements, the architecture evolved in a way to improve release flow. This kind of change is disruptive, but luckily, there's already some good design patterns that can help us to succeed in this complexity.

Microservices introduction

Microservices is a huge movement in software architecture nowadays. This talk present the origin, the benefits and some pitfalls to be aware of while adopting this kind of architecture.

Clean Architecture with legacy code

How to integrate clean architecture in legacy applications gradually.​

Technical Debt

Did you ever work on a software rewrite project that was supposed to solve all previous design problems? Was it finally the case? Sure not.

Technical debt is a normal phenomenon in software and any developer should be aware of it. What's causing it? How to solve it? Can we measure it? Of course!