@sylvain-martel_3976 thanks for the additional information; I'm warning up to this idea, but there's a one main area of concern
Are you sure WinGet can help you achieve "Infrastructure as Code"? I'm becoming more and more skeptical of this use case.
The main reason is that there are very few server applications on Microsoft's public WinGet repository. Even their own products like SQL Server aren't there. It's mostly desktop tools like Adobe Reader, Visual Studio, etc. This tells me Microsoft doesn't see WinGet helping with IaC, either.
This is largely the same concern I had with Chocolatey, in particular organizations trying to use Chocolatey for IaC. Their public repository is mostly desktop tools, and using Chocolatey to manage server-based applications is really difficult.
This has really nothing to do with Chocolatey or WinGet, but more that server-based products tend to require infrastructure configuration (user accounts for services, certificates for websites, IP address bindings, firewall changes, database connection strings) -- where as a tool like Adobe Reader simply does not. And infrastructure changes like this are rarely automated as part of the installer.
I definitely get the use case of WinGet (or Chocolatey) as means to distribute desktop applications, and if that were the case - there's a lot more features we need to consider (like proxying Microsoft's public gallery, etc.).... but at the moment I'm just not seeing it for IaC / Server applications.
Perhaps, try doing a proof of concept on your end? I guess you just need to set up a Git Repository, and then, there's your basic WinGet repo?
Ultimately using WinGet in an IaC scenario sounds like a bit more work (and more moving pieces) than just running a PowerShell script to download and run a handful of installers... but I don't know.
I'd love to see what you put together, or more specifics as you learn them yourself.